Open yomnxkcs opened 3 years ago
这是一项高级特性(普通人就老老实实写单json就好了),更简洁、完全的适用范围更是它的主要诉求,至于实用不实用看你自己的领会能力和运用规则的能力:
补充:
并且你的理解有误,目前的逻辑,inbound位于数组中,你举例的两项会合并成2个相同的default-inbound
,合并根本到不了user这一层。合理运用规则的做法是,同一个inbound就不要分开写:配置文件就在那里,直接改了第一个的user就好,何必舍近求远,不嫌麻烦地再写一个,让程序去合并。
合并的意义在于不同功能配置的“组装-拆卸”,而非修改某个值。
对,我大意了,没注意inbounds本身是一个数组。所以新的合并规则只能加in/out bound而不能修改in/out bound。那么使用范围比原来的合并规则更小了。
正因为不同人有不同需求我才用settings -> accounts
来举例。目前的合并规则,两种结果都可以实现。而新规则只能实现其中一种。
新的合并规则比现在的规则更实用吗?
我只不过觉得合并相同tag没什么用(如我所说,我关注的是功能模块的拆装,而非修改特定值)。
其实也不难:
现在支持合并,这里有示例: https://github.com/qjebbs/v2ray-core/blob/map_json_loader/infra/conf/merge/merge_test.go
不太懂代码,合并规则还是让项目组来决定吧。不管用哪种合并规则,都希望提供输出到文件功能,不然查错很麻烦。
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days
现在使用多文件配置的时候,最后配置合并成什么样基本靠猜。所以建议添加把合并后的配置输出到文件的功能,以便于发现、修改错误配置。具体大概像这样:
v2ray -c basic.json -c log.json -confdir /home/user/routings/ -debug > merged-config.json
另外 v2fly/v2ray-core PR #451 的合并规则看上去很美,但实用吗?用inbound来举个例子。 假设我想通过多配置文件功能把inbound由socks改成http。 socks的配置如下(已省略不重要的配置):
http的配置如下:
如果我没理解错的话,合并后的
settings -> accounts
应该是Alice和Bob同时存在。显然这并不是我想要的结果。 对于这个特例也许有办法解决,但是还有routing等更复杂的情况呢?