[Feature] <增强"rule groups"的 可配置性，添加诸如sub-rule、更多条件判断……等等> about clash

[Accademia]

if field is the same as the shortcut syntax and if none of the sub-rules match, then continue to match the next rule.

你真的看得懂这句话的意思吗？

你真的看懂了我写的意思了吗？

[Accademia]

好好看看 Script Shortcuts 目前可以用哪些内置变量吧。

https://dreamacro.github.io/clash/premium/script-shortcuts.html#variables

上面描述的通篇都是在将如何完善规则本身，而非脚本。

[Accademia]

if field is the same as the shortcut syntax

问题是 if 字段使用的是跟 Script Shortcuts 脚本一样的语法啊。

感谢回复。下面，从两个方面来阐述观点：

• 首先，如果说 https://dreamacro.github.io/clash/premium/script-shortcuts.html#variables 中的变量，已经可以在Rule-Group中的IF条件判断中，已经使用了，那的确是非常好的一件事。当然，还是希望增加更多的全局变量，比如Process_Name或SSID等等，用以满足更多分流算法。

• 其次，除了，为IF添加更多条件判断之外，我的帖子，还建议再次补充 Clash Rule中缺少的更多功能（如子规则、子规则的接口声明、子规则之间套娃 、子规则的接口赋值……等）。当然，此时，也许会有人说，Script 可以代替Rule实现更灵活的配置。所以，没必要重新造轮子，去为Rule添加更多功能。如果面对这样的问题，那我们是否能反问，C语言里面的 if else，跟 汇编语言中的Branch指令，不也是一样的语法？？所以，既然都一样，难道，汇编 = 包打天下 ？还需要高级语言干什么用？

• 所以，同理，用 “脚本” 去割裂 “规则”（用脚本 为规则 打补丁），是否是，解决本Issue（如何 封装分流算法、如何提到 分流算法的 维护效率）的最优解法？

[Accademia]

if field is the same as the shortcut syntax

问题是 if 字段使用的是跟 Script Shortcuts 脚本一样的语法啊。

关于：是否要，进一步，丰富Rule功能，以便能代替 手撸Script ？

也就是说，也就是说，如果，《Script 》和 《本楼中首贴中的建议功能》，两者核心功能，大致等价，是否有必要，再造轮子？

其实，只要，图灵完备的《编程语言或指令集》，那在功能上，必定都是彼此全等价的。

而不同语言（或，类-语言）能在垂直市场有受众，必定面向《特定目标》的效率（尤其是维护效率，其次是编写效率），是行业内 最优解。

脚本Script Shortcuts这种《打补丁》的方式，是不是《封装、维护》高级功能（如，封装 分流算法）的最优解，从其市场渗透率（使用渗透率）角度来看，已经自有定论了。

---

我上面给的所有的，发展建议，都围绕着，yaml文件内《 代码可维护性 & 更高效的封装》这两个前提下，进行展开的。不然Script Shortcuts已经能实现的部分公司，完全没必要再分配开发资源 、再造轮子。

至于 代码的 维护效率 和 封装效率 ，有多重要，值不值得造轮子，给你讲个行业案例。

要知道，从60年代 ~ 70年代，整个硅谷花了将近20年，都在研究，如何做出更NB的复杂指令集。为什么？因为其核心目标只有一个，就是如何通过更复杂的指令集， “提高软件代码的 生产、维护效率” 。

但最终发现，无论设计，多复杂的指令集（多复杂的间接寻址机制、或多复杂的条件跳转机制、或多复杂的多正交功能操作的复合功能指令），其对应汇编代码，的生产、维护效率，也完全赶不上高级语言（C语言）代码，生产维护效率的1% 。最终，在70年代末，整个美国 凡是涉及到复杂指令集的计划，统统破产，无一例外。包括IBM在内的所有公司，研发复杂指令集的开发团队，统统被打包带走，资源被释放，并分配到了高级语言编译器项目上。说白了，对于 代码的 封装 维护 效率、来说，全球所有公司用了20年去证明了，在复杂指令集（汇编）上 无论怎么改进，就算雕出花来，也是0。而此后的50年来，各种 语言 或 类语言，的发展，也都是遵寻了，上述相同的路线。最终达到的结果就是，究竟要设计什么样的语法规则，才能在特定垂直目标市场内，让NB和SB的程序猿（或非程序猿），都可以写出质量大致相同的东西，而且都写的极快，且极易让 后续的 维护者理解。

而Clash路由配置 的发展，是否也应该遵循相同的轨迹？

比如，到底是应该设计出，更平缓学习曲线 + 易于维护代码 ，的Rule Code？还是继续 加强，脚本Script编程 功能（让更多用户学会编程）？

• 在我看来，Rule的目标： 易用 易学 + 涵盖 99% 使用场景
• Script Shortcuts的目标： 灵活 强大 + 涵盖 1% 使用场景

更进一步说，Script Shortcuts，看起来就像是维护一个《 补丁大合集》，而在Rule中使用Script Shortcuts，就像是用补丁，去覆盖rule 无法实现的功能。对代码的连续性，造成的是《割裂》，而非最优解。而且，在本Issue中提到一些Feature，Script Shortcuts也并未完全覆盖。

[Accademia]

https://github.com/MetaCubeX/Clash.Meta

我之前是看过Clash.Meta。

先说结论：

• 从《可维护性、可读性》，这俩角度来说，本项目的Rule Group写法，秒杀Clash.Meta的 竞品功能，至少100条街 ！！~~

对比一下：

# ------------
# Clash.Meta
# ------------
- AND,((DOMAIN,baidu.com),(NETWORK,tcp)),DIRECT

# ------------
# Clash官方版
# ------------

  - if: (network == 'tcp') 
    rules:
     - DOMAIN-SUFFIX , baidu.com DIRECT

或（未来）

  - if: (network == 'tcp') & (DOMAIN-SUFFIX == 'baidu.com')
    rules:
     - MATCH, DIRECT

你认为上述两者，哪种可读性更强？

非常明显，一旦条件判断，发生膨胀。那么， Clash.Meta那种写法，其可读性（可维护性），会指数级下降。

最终，上述俩，其可维护性（可读性）相比，就像 Perl 与 Python之间的差异一样。Perl 被 Python后来居上，不是没有原因的。现在也就是做IC Design front-end Flow的半导体公司，才会 有时间 + 有钱（为了追求：必须100%条件路径测试覆盖 + 必须0 Bug Sign-Off），去雇“人均 > 80~100万 Package”的验证工程师，去继续死磕Perl脚本。

当然，最后在补充两点：

1. 我在本issue中提到的Feature，在Clash.meta中也没有全部实现，比如带有接口的子规则（为了最大限度，提升，封装性）。
2. Clash.Meta的稳定性，是不用他们的另一个主要原因。尽管他们实现了很多，痛点功能。但也只能忍痛不用。

[Accademia]

# ------------
# Clash官方版
# ------------
或（未来）

  - if: (network == 'tcp') & (DOMAIN-SUFFIX == 'baidu.com')
    rules:
     - MATCH, DIRECT

为什么要 '或（未来）'，而不是现在？

rules:
  - if: network == 'tcp' and host contains 'baidu.com'
    name: BaiduTCP
    rules:
      - MATCH, DIRECT

  - if: network == 'tcp' and (resolve_process_name() == 'IDMan.exe' or hasPrefix(resolve_process_path(), 'C:\\Program Files (x86)\\Internet Download Manager\\'))
    name: Download
    rules:
      - MATCH, DIRECT

非常好。

当然，如果能有，更便捷的 “语法糖”，那就更好了。

希望以后能有吧

[fakeboboliu]

你打了很多，引经据典口若悬河，但是我基本没有看，这个叙述太痛苦了

我先确认两个点，首先这里大部分的用户和为项目做出改善和衍生的，是程序员
所以对于所有提升易用性的点，首先要考虑的是实现的严谨和标准，保证有逻辑思维和一定相关背景的人可以准确无误地快速理解
而不是做成 Excel 那种需要专门学的狗屎表达式

另外，提出任何问题，建议在 issue 中最好不要先大段叙述产品经理语，先谈实现思路，否则通常不会有人理（不过这个 issue 靠字多打破了这个规律）
如果你想辩这个经的话有很多群聊可以去，比如 Clash 的群或者隔壁 Meta 的群

[fakeboboliu]

回来看一眼我的拉黑被解了，看来是喷我的消息终于编辑完了

虽然不知道哪句戳到你的 G 点了，我就不继续热脸贴冷屁股了，
希望楼主自己阅读一下自己的排版，看看社区其他生态，我并没有恶意，只是在说一些事实。

[Accademia]

什么叫 “语法糖“ 都已经实现“”？？？？

很明显，从可读性（避免出BUG）角度来说。未来，语法糖，可以给与，更大的优化空间。很明显，目前IF条件判断，引用的表达式，跟目前的规则（Rule），完全是俩 “风味”。

如果不明白，可以对比如下。哪个有更平缓的学习曲线，以及一致性的 “编写风味”。

 - if: network == 'tcp' and host contains 'baidu.com'
 # 对比
 - if: (network == 'tcp') and (DOMAIN-SUFFIX == 'baidu.com')

- if: network == 'tcp' and (resolve_process_name() == 'IDMan.exe' or hasPrefix(resolve_process_path(), 'C:\\Program Files (x86)\\Internet Download Manager\\'))
# 对比
 - if: network == 'tcp' and (PROCESS-NAME == 'IDMan.exe' or PROCESS-PATH == 'C:\Program Files (x86)\Internet Download Manager\')

横向对比，哪种，有更平缓的学习曲线？更少的笔误？更易于的可读性？

就冲上述这两段代码的差异性，恐怕， 你压根不知道什么叫 《语法糖》？

如果还不能理解，建议补补C++的发展史，是如何从 C 的一种编程风味，跃升进化到 “面向对象” 的。

当然，还是非常感谢，提供了Wiki上面没有的示例，以至于，让“对比性” ，更加完整。同时，也让讨论变得更加清晰。毕竟 ，道理还是越辩越明。

[Accademia]

单就这个常量代替求值确实可以通过 patch 和运算符重载在 expr 中实现，直接把常量替换成函数 call 也能保持懒求值减少性能影响，但是规则多的话预编译这些脚本会延长不少启动时间，常量名也有待商榷。

另外如果真的要匹配 suffix的话，用 == 显然是非常不妥的，语义上疯狂打架。

非常感谢回复。是的，你提的这些质疑，都是合理的。

本Issue提交，并非 精确解。因为本人看到，Rule Group的 潜力，的确比Clash.Meta要高出不少，所以，本Issue只是延续官方Rule Group的思路，继续推演。究竟什么样的“条件分支”和 “规则封装”（规则套娃）是更易懂、更易于维护、学习。总的来说，在您提到的那些细节上，本Issue，纯纯催催的，“0打磨”。而仅作为思路，拱讨论。

所以，最终，如果有机会能实施 能定稿，肯定还需要更多的，功能修正、产品打磨。

就拿上述提到的==来说，对于面相《非编程》用户的Clash Rule来说。我相信99%的人，压根搞不明白，下面这俩操作符之间，的区别：

• == 与 = 的区别

所以，可以看到，excel、Python，同样都可以做数据处理，但Excel中，就极力避免==和=撞车，凡是要条件判断的地方，在“Excel的公式”中，都是用=操作符，而非==。如：

=IF(C2=E3,”Yes”,"NO")

上述这种写法，这在其他语言中，是很非常不常见的、或极力避免的。先不论EXCEL这种方式，在代码维护的效率上，是好是坏，但能做出这样的妥协，一定是与目标受众相关的。说白了，能用Excel写公式（制作自动化Excel表格），哪怕处理单一一个Excel文件就要数百MB的主儿，也八成依然不会编程（包括Python和VBA编程）。

像您提到的，有部分细节问题，我也认为，还需要更多权衡。本文只是提供思路。最终，如何让，Clash Rule这些非程序员用户，依然有足够低的学习曲线 和 代码维护效率。

[Accademia]

请你直接指出具体问题，尤其是有建设性的具体解法。而不是说一堆《狗屎一样的自我喜好 》，更不是展示《自己的狗屎思维》造就的 《鄙视链+优越感》，那纯浪费彼此时间。而且对看帖Review的人，0意义。

请展示你的《具体方法、具体方法、具体方法》。重要的事情说三遍。

用鄙视链、个人喜好、或Show自己的优越感，去引战式的，对《整个技术性讨论话题的讨论方向》进行破坏，试图带歪《纯技术讨论》氛围的，而非建设它（提出建设的解法），难道不是最不可取的、最不高效的、最不应该被推广的方式？

在首楼中，罗列了五个问题 以及相关代码。

但只能说，首楼的代码（面向五个问题的解法），纯纯粹粹是伪代码级别的玩意儿（可能都算不上），因为我自己都觉得， 诸多解法的“细节”，都太不严谨，更远非完美。顶多算是《伪代码级 的 原型功能描述》。

所以，面对首楼这些问题。你的建设性解法，在哪？？？？

最终，核心问题就一个：

• 如何提高，封装效率 以及 维护效率（学习成本）

---

ps：另外，关于你说的那两点。我是今天，才从你这里知道，按你说的，能用clash或小火箭的数千万用户，能在这些app中能配置修改规则的用户，《绝大部分》都是程序员……。

说白了，如果能继续讨论首楼的问题，像您下的这些结论，我都不关注也不评价。在我看来，继续推进功能演进，远比彼此“教育对方”，更重要。

希望，您下个回复 ，能仅仅仅仅展示“解法”，纯干货，聚焦细节本身。谢谢

[Accademia]

乐了，我心想什么讨论串能串这么长，一点进来发现题主把我拉黑了，还拉黑了两个号。 再一看是老朋友啊，之前提议被否了又来，你搁这上访呢？ 我的意见是不发钱装什么产品经理，写这么一大串大伙懒得看更不会做，不如你速速提交 PR.

建议， @Dreamacro ，清除专门引战的《小号》。清除与本Issue无关的帖，以保证纯技术探讨，和纯技术讨论中，《有效信息》的密度。（如果可以，连同本楼层一起清除）

对于一个90年就沉迷于撸各种指针BUG的，老Architect提出的“问题”（可能都谈不上解法），我相信。作者（@Dreamacro）肯定是识货的。对于，目前Clash项目，所面对的，《语言的演进 + 有限的产能》，肯定更要谨慎落笔。另一方面，对于一个数千万用户级别的产品，没有冷嘲热讽，是不可能的。对于一个项目来说，《没人关注》才是最大的死，其他的都可以说是《正向反馈》，所以，出现上一层这种《纯引战帖》，也不奇怪。

但是，希望，@Dreamacro 大，还是能在看帖之余，顺手最大限度维护，社区中纯技术讨论。清除一切引战、或与话题无关的东西。

回复本Issue，核心是：

• 展示《解法》，或，为什么否定《解法、或问题》。

[Accademia]

说说我对《条件分流》和《子规则封装》的看法。

首先，目前的已实现功能的 Clahs Rule + Script， 已经能满足>90%的场景需求了。就算，按首楼提出的5个问题，能全部解决，我估计使用这些“条件判断”和“子规则封装”功能的人，依旧连10%都没有。

为什么？

因为，目前，Clash Rule，主要目的是，《根据 网址链接地址，进行分流》。其，目标地址，纯纯的都是静态的（没有啥需要动态判断的地方），IF需求并不强劲。（想反驳，端口分流需求的 ，请往后看）

---

那如此低渗透率，《条件分流》和《子规则封装》的意义在哪？

如果未来的，用户需求，升级成为， 《根据不同APPs（或不同场景），进行分流》呢？即，针对不同的APPs，配置不同的分流规则。在这样的情况下，IF判断 和 Sub-rule套娃，恐怕就是必须的了。

也就是说，未来，如果有更多的《外部变量》控制Rule，那么，Rule中的《IF和 子规则接口》 ，才有价值。

不然，为执行路径添加 “跳转”功能（跳入 封装好的、带有接口的 子规则），则为非 “广泛性的 刚需”。

---

当然，如果此时要问，为什么要给不同APP配置不同的分流规则。我要有几百个APP，我配置的过来？

所以才要更强的封装，以便能订阅“子规则”后直接调用……。虽然目前还都是全民手撸Rule，我相信，未来内置不同“Sub-Rule”的Rule Store，看似也只是时间问题。

再补充一句：需求，也并非一定是，来自于APPs。像TCP UDP 端口号、SSID、LBS位置、外网IP、剩余电量……等等，总之《非静态网址》的东西，都可算是，执行路径“跳转”，所需的《控制变量》。

总之，IF＋变量，才能驱动《动态跳转》。IF＋常量，只会《固定顺序》的执行。

---

当然，我相信，即便未来实现了《更强语法糖》的《条件分流》和《子规则封装》。作为最终用户（使用者），也要尽量少的IF和尽量少的子规则。毕竟每一次跳转（执行路径的改变），都意味着，性能的降低，尤其是Jump后的地址发生了Cache Miss。（需要频繁现加载规则）。即，能通过调整，规则的顺序，实现功能，就尽量少用IF。

这就好比，底层语言的性能调优或功耗调优，在各种基于指针（或手动寄存器分配）的语言当中，乱用语法，造成的性能差异超过100倍，同样也完全不奇怪。（当然 这个情况有些极端）

[Accademia]

回来看一眼我的拉黑被解了，看来是喷我的消息终于编辑完了

虽然不知道哪句戳到你的 G 点了，我就不继续热脸贴冷屁股了，

希望楼主自己阅读一下自己的排版，看看社区其他生态，我并没有恶意，只是在说一些事实。

如果，对于非技术性issue。你发这种帖子 （不为主话题 提供解法的帖子），我都无意见。包括 你这种，纯发泄情绪贴，或0信息量的鄙视链贴，我都无意见 也压根不关注。

但对于本帖 ，多次强调，只聚焦，纯《解法》性质的讨论。 （而其他话题，建议找当事人私聊，而不是占用公共楼层，更不是通过发泄私欲，破坏技术讨论的话题方向）

所以，只能 暂停您回复本贴，不好意思了，直到本话题结束。

---

总之，如果认为，本issue所提功能 极大非合理性，也希望能从《解法》角度，指出问题。并且，最好、最好、能提出《更好的解法》。

总之，希望，下面新帖，能进一步：

• 聚焦《解法》

[yaling888]

if field is the same as the shortcut syntax and if none of the sub-rules match, then continue to match the next rule.

你真的看得懂这句话的意思吗？

[yaling888]

# ------------
# Clash官方版
# ------------
或（未来）

  - if: (network == 'tcp') & (DOMAIN-SUFFIX == 'baidu.com')
    rules:
     - MATCH, DIRECT

为什么要 '或（未来）'，而不是现在？

rules:
  - if: network == 'tcp' and host contains 'baidu.com'
    name: BaiduTCP
    rules:
      - MATCH, DIRECT

  - if: network == 'tcp' and (resolve_process_name() == 'IDMan.exe' or hasPrefix(resolve_process_path(), 'C:\\Program Files (x86)\\Internet Download Manager\\'))
    name: Download
    rules:
      - MATCH, DIRECT

[yaling888]

# ------------
# Clash官方版
# ------------
或（未来）

  - if: (network == 'tcp') & (DOMAIN-SUFFIX == 'baidu.com')
    rules:
     - MATCH, DIRECT

为什么要 '或（未来）'，而不是现在？

rules:
  - if: network == 'tcp' and host contains 'baidu.com'
    name: BaiduTCP
    rules:
      - MATCH, DIRECT

  - if: network == 'tcp' and (resolve_process_name() == 'IDMan.exe' or hasPrefix(resolve_process_path(), 'C:\\Program Files (x86)\\Internet Download Manager\\'))
    name: Download
    rules:
      - MATCH, DIRECT

非常好。
当然，如果能有，更便捷的 “语法糖”，那就更好了。
希望以后能有吧

什么叫“希望以后能有吧”，这些都是已实现的功能啊，复制粘贴就能用，慢慢去发现吧。

rules:
  - if: network == 'tcp' and host contains 'baidu.com'
    name: BaiduTCP
    rules:
      - MATCH, DIRECT

  - if: network == 'tcp' and (resolve_process_name() == 'IDMan.exe' or hasPrefix(resolve_process_path(), 'C:\\Program Files (x86)\\Internet Download Manager\\'))
    name: Download
    rules:
      - MATCH, DIRECT

[yaling888]

好好看看 Script Shortcuts 目前可以用哪些内置变量吧。

https://dreamacro.github.io/clash/premium/script-shortcuts.html#variables

[yaling888]

if field is the same as the shortcut syntax

问题是 if 字段使用的是跟 Script Shortcuts 脚本一样的语法啊。

[iKira]

https://github.com/MetaCubeX/Clash.Meta

[fakeboboliu]

单就这个常量代替求值确实可以通过 patch 和运算符重载在 expr 中实现，直接把常量替换成函数 call 也能保持懒求值减少性能影响，但是规则多的话预编译这些脚本会延长不少启动时间，常量名也有待商榷。

另外如果真的要匹配 suffix的话，用 == 显然是非常不妥的，语义上疯狂打架。