Destructive Command Guard 正则引擎选型决策实录为何不采纳 regex-automata DFA 后端【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard本篇文章完整还原 Destructive Command Guarddcg在 ksk.8 任务中针对regex-automataDFA 后端的一次工程决策过程从可行性评估ksk.8.1到决策门ksk.8.2再到最终以 DEFER/DROP 收官的完整闭环。你将看到 dcg 现有的regexfancy-regex双引擎架构为何在基准测试中反而胜出以及一个成熟安全工具在面对换引擎诱惑时如何用数据说话、守住性能预算与二进制体积底线。读完后你既能掌握 dcg 正则匹配层的真实设计与性能预算体系也能复用这套先基准、后决策、可回访的依赖选型方法论。决策背景为什么 dcg 会考虑引入第三个正则引擎dcg 是一款拦截 Agent 执行危险 git 与 shell 命令的 AI 编码助手钩子hook其核心工作是对每一条即将执行的命令做快速安全评估。正则匹配是这条链路上最密集的计算之一因此引擎选型直接关系到 hook 的端到端延迟。dcg 当前采用双引擎架构统一封装在 src/packs/regex_engine.rs 的CompiledRegex枚举中Linear(regex::Regex)使用regexcrate提供 O(n) 线性时间保证不支持前瞻/后顾/反向引用Backtracking(fancy_regex::Regex)使用fancy-regexcrate支持前瞻lookahead、后顾lookbehind、反向引用等高级特性。根据源码模块注释dcg 的正则安全审计git_safety_guard-99e.11发现约85% 的 pack 规则可以用线性时间的regexcrate仅约15% 需要前瞻/后顾等回溯特性。CompiledRegex::new()会调用needs_backtracking_engine()做语法启发式判定自动为每条规则选择引擎若线性引擎编译失败还会回退到回溯引擎重试保证高级语法不漏配。正是在这种架构下ksk.8 任务提出疑问regex-automataRust 生态中由regex团队维护的更底层 DFA/NFA 引擎能否替代或补充现有双引擎获得更好的 ReDoS 抵抗力、统一 API 或多模式匹配优化于是有了 ksk.8.1 的可行性报告与原型基准docs/regex-automata-feasibility-report.md以及 ksk.8.2 的决策门即本决策备忘录 docs/regex-automata-decision-memo.md并最终在 docs/decision-dfa-backend.md 中正式关闭。基准测试设计对照实验的严谨之处可行性研究没有停留在纸面推演而是把regex-automata作为dev-dependency引入见 Cargo.toml 中regex-automata 0.4 # For ksk.8.1 prototype comparison并编写了专门的 Criterion 基准 benches/regex_automata_comparison.rs。这套基准设计有几个值得借鉴的要点使用真实业务模式从 dcg 各 pack 中抽取代表性规则包括git-reset-hard、git-clean-force、git-push-force、rm-rf、docker-prune、kubectl-delete、drop-table、truncate覆盖从简单线性模式到大小写不敏感模式。混合正反样本测试命令集既包含会命中的危险命令git reset --hard HEAD~5、rm -rf /var/log/old也包含应被快速拒绝的安全命令git status、ls -la专门检验快速拒绝路径。多维指标覆盖编译时间、单模式匹配is_match/find、多模式 pack 模拟顺序扫描 vs 组合交替、ReDoS 病态模式、长输入吞吐五个维度。使用black_box防止优化作弊所有输入均经过std::hint::black_box确保基准不会被编译器优化掉。关键基准数据全面解读五组对照结果1. 编译时间regex-automata 明显吃亏模式regexregex-automata差异git-reset-hard~4.8µs~6.8µs42% 更慢git-clean-force~4.5µs~6.2µs38% 更慢rm-rf~5.2µs~7.1µs37% 更慢drop-table~3.1µs~4.9µs58% 更慢regex-automata 的编译开销普遍高出 40%60%。虽然可行性报告指出 dcg 的LazyCompiledRegex模式OnceLock惰性编译每个模式只编译一次可以缓解这一劣势但编译开销仍会真实地体现在冷启动场景中——尤其是 hook 是一次性进程时。2. 单模式匹配几乎打平甚至略慢操作regexregex-automata差异is_match~47ns~48ns~2% 更慢find~49ns~52ns~6% 更慢两者都达到 sub-50ns 的匹配速度。结论是替换引擎并不会带来匹配性能提升。3. 多模式 Pack 模拟顺序扫描无优势场景regexregex-automata差异顺序扫描命中~75ns~78ns~4% 更慢顺序扫描未命中~312ns~318ns~2% 更慢组合交替模式~58ns~61ns~5% 更慢dcg 当前的 pack 评估方式是逐条规则顺序is_match两条引擎在这种工作负载下表现几乎一致。4. ReDoS 病态模式唯一亮点但意义有限模式regexregex-automata状态(a)$~15ns~16ns两者均 O(n)(a|a)~22ns~15nsautomata 快 32%(a*)*b~22ns~16nsautomata 快 27%这是 regex-automata 唯一取得明显领先的维度。但正如决策备忘录强调的regexcrate 本身基于 Thompson NFA已经提供 O(n) 保证两个引擎都能在 O(n) 时间内处理灾难性回溯模式因此这 27%32% 的差距属于锦上添花并非刚需。5. 长输入吞吐均远超预算输入大小regexregex-automata吞吐100 字节210ns201ns~520 MiB/s1KB1.48µs1.49µs~650 MiB/s5KB7.16µs7.16µs~665 MiB/s10KB14.3µs14.4µs~667 MiB/s两者在长输入上几乎一致稳定在 ~650 MiB/s 的吞吐水平远在 dcg 的性能预算之内。性能预算体系决策背后的标尺决策备忘录反复引用所有性能预算see src/perf.rs这并非虚指。dcg 在 src/perf.rs 中定义了分层性能预算表作为 CI 基准强制、运行时受限评估阈值与文档预期的唯一事实来源source of truth层级路径目标超过告警超过恐慌0Quick reject关键词快速拒绝 1µs 5µs 50µs1Fast path安全命令快速路径 75µs 150µs 500µs2Pattern match完整模式匹配 100µs 250µs 1ms3Heredoc 触发检测 5µs 10µs 100µs4Heredoc 内容提取 200µs 500µs 2ms5脚本语言检测 20µs 50µs 200µs6完整 heredoc 流水线 5ms 15ms 20ms此外hook 整体评估有1000ms 的绝对预算HOOK_EVALUATION_BUDGET_MS超时返回显式不确定indeterminate结果绝不会把不完整的分析静默转化为 allow。src/perf.rs 中还内置了大量测试如budget_documentation_matches_source_of_truth确保 README、AGENTS.md、CI 中的预算文案与代码常量保持同步防止文档漂移。正是这套预算体系让引入 regex-automata的成本一目了然即便匹配延迟只增加 2%6%其收益略微更好的 ReDoS 表现在现有 O(n) 保证面前毫无意义。现状评估dcg 已经不需要新引擎决策备忘录对现有实现给出的评估是满足所有性能预算基准定义见 src/perf.rsCI 有基准强制与回归检测99% 的命令在正则之前就被快速拒绝dcg 使用aho-corasick多模式字符串匹配构建关键词索引见 src/packs/mod.rs 中pack_aware_quick_reject与build_enabled_keyword_index对不含任何危险关键词的命令在进入正则阶段前就以接近 1µs 的成本放行对应预算表中的 Tier 0惰性编译摊薄模式编译成本LazyCompiledRegex见 src/packs/regex_engine.rs在包注册表初始化时只保存模式字符串OnceLock保证首次使用才编译、多线程竞争只编译一次显著改善允许路径的启动延迟已具备 O(n) ReDoS 抵抗力线性引擎 100,000 步回溯上限BACKTRACK_LIMIT双保险回溯超限时 fail-open 返回false/None见 regex_engine.rs 的测试test_pathological_backtracking_fails_open保证病态模式在亚毫秒内完成而非挂起数秒。值得一提的是即便是必须使用回溯引擎的 15% 高级模式dcg 也通过BACKTRACK_LIMIT 100_000将最坏情况评估时间限制在约 1ms 内现代硬件约 10ns/步正好落在PATTERN_MATCH预算的 panic 阈值内。成本收益分析为什么结论是不采纳性能结论决策备忘录核心表指标当前regexregex-automata结论匹配延迟~47-49ns~48-52ns无收益慢 2-6%Pack 评估~75-312ns~78-318ns无收益慢 2-4%ReDoS 模式~15-22ns~15-16ns轻微收益无意义编译~4-5µs~6-7µs更差慢 40-60%两个引擎都已提供 O(n) 保证因此 ReDoS 改进可以忽略不计。维护成本决策备忘录评估因素影响评估第三个正则引擎高增加CompiledRegex枚举复杂度特性开关管理中可选依赖增加构建矩阵复杂度模式分类中必须决定哪些模式用哪个引擎文档负担低需要解释更多引擎选项二进制体积当前发布二进制39 MBrelease、LTO、stripped预计增加 200-400KB2-5%与项目opt-level z的体积优化理念冲突。这一点在 Cargo.toml 中有直接印证release profile 采用opt-level z、lto true、codegen-units 1、panic abort、strip true全部为缩小分发体积服务同时为恢复正则编译速度专门对regex、regex-automata、regex-syntax、fancy-regex、aho-corasick等 crate 单独设置opt-level 3详见 Cargo.toml 中[profile.release.package.regex]等小节。这组配置说明 dcg 对二进制体积和启动延迟的敏感度极高——任何2-5% 体积的代价都会被认真对待。成本 vs 收益成本匹配慢 2-6%、编译慢 40-60%、二进制增大 2-5%、维护负担增加收益略微更好的 ReDoS 抵抗力不需要、统一 API不具说服力。结论不言自明。决策备忘录的最终定论是Do not adopt regex-automata at this time.当前不采纳docs/decision-dfa-backend.md 将其状态定为 CLOSED - DROP并明确指出关键发现——regex-automata 在所有实测操作上实际更慢而非更快唯一改进是病态 ReDoS 模式快 27%32%而两个引擎本就都是 O(n)。曾考虑过的替代方案与最终取舍可行性报告和决策文档共同梳理了三条技术路线Option A整体替换不推荐处处用regex-automata::meta::Regex替换regex。缺点是编译时间更高、丢失RegexSet优势——后者在 heredoc 触发检测中正被使用src/heredoc.rs 用regex::RegexSet实现单遍并行匹配对应预算表 Tier 3 的 5µs 目标。Option B混合方案曾推荐后否决保留现有架构仅对高频模式git-reset-hard、rm-rf 等使用预编译 DFA继续OnceLock惰性编译fancy-regex保留给 15% 前瞻/后顾模式。可行性报告曾建议谨慎推进但决策门评估后认为复杂度成本超过边际收益予以否决。Option CRegexSet 优化留待未来利用多模式匹配构建单个 DFA 一次扫描替代顺序评估潜在 3-5 倍加速——但决策文档明确指出该路线可以独立于 regex-automata 探索不构成现在引入依赖的理由。未来重新评估的触发条件决策不是永恒的。备忘录明确列出四条回访触发条件供后续维护者判断何时应重新打开这个议题性能回归若 pack 评估超出预算当前目标 ~100µs多模式优化若 ksk.8 Option C 的 RegexSet 方案出现显著收益依赖整合压力若fancy-regex被弃用或停止维护体积约束放松若分发约束放宽二进制体积不再关键。docs/decision-dfa-backend.md 中还补充了若 regex-automata 新版本获得显著优势或多模式匹配成为瓶颈也应重新评估。行动项与基准复现决策备忘录给出的行动项保持regex-automata仅为 dev-dependency仅用于基准对比生产二进制不受影响以本决策文档关闭 ksk.8.2考虑将 ksk.8 父任务标记为 deferred归档基准代码于 benches/regex_automata_comparison.rs供未来参考。复现这套基准的命令来自备忘录附录与可行性报告# 运行 regex vs regex-automata 对比基准 cargo bench --bench regex_automata_comparison # 验证当前性能满足预算 cargo bench --bench heredoc_perf # 运行 E2E 回归测试 ./scripts/e2e_test.sh其中heredoc_perf基准benches/heredoc_perf.rs覆盖 quick reject、fast path、heredoc 触发/提取、语言检测与完整 heredoc 流水线与 src/perf.rs 中的预算表一一对应是验证 dcg 性能健康状况的主要手段。结语一次教科书式的不换引擎决策回顾整条决策链可行性研究用严谨的对照基准给出数据 → 决策门基于性能预算、维护成本、二进制体积三维评估 → 最终以 DEFER/DROP 收官并把触发条件与基准代码完整归档。这个案例对任何正在做依赖选型的团队都有参考价值当更先进的引擎在真实工作负载上既不更快、也不更小、还更复杂时保守维持现状并用文档固化决策本身就是一种高质量工程决策。而 dcg 用aho-corasick关键词快速拒绝、LazyCompiledRegex惰性编译、BACKTRACK_LIMIT回溯上限与分层性能预算已经构筑了一条足以支撑 sub-50ns 匹配、~650 MiB/s 吞吐的正则防线——这正是它敢于对 regex-automata 说不的底气所在。【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Destructive Command Guard 正则引擎选型决策实录：为何不采纳 regex-automata DFA 后端
Destructive Command Guard 正则引擎选型决策实录为何不采纳 regex-automata DFA 后端【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard本篇文章完整还原 Destructive Command Guarddcg在 ksk.8 任务中针对regex-automataDFA 后端的一次工程决策过程从可行性评估ksk.8.1到决策门ksk.8.2再到最终以 DEFER/DROP 收官的完整闭环。你将看到 dcg 现有的regexfancy-regex双引擎架构为何在基准测试中反而胜出以及一个成熟安全工具在面对换引擎诱惑时如何用数据说话、守住性能预算与二进制体积底线。读完后你既能掌握 dcg 正则匹配层的真实设计与性能预算体系也能复用这套先基准、后决策、可回访的依赖选型方法论。决策背景为什么 dcg 会考虑引入第三个正则引擎dcg 是一款拦截 Agent 执行危险 git 与 shell 命令的 AI 编码助手钩子hook其核心工作是对每一条即将执行的命令做快速安全评估。正则匹配是这条链路上最密集的计算之一因此引擎选型直接关系到 hook 的端到端延迟。dcg 当前采用双引擎架构统一封装在 src/packs/regex_engine.rs 的CompiledRegex枚举中Linear(regex::Regex)使用regexcrate提供 O(n) 线性时间保证不支持前瞻/后顾/反向引用Backtracking(fancy_regex::Regex)使用fancy-regexcrate支持前瞻lookahead、后顾lookbehind、反向引用等高级特性。根据源码模块注释dcg 的正则安全审计git_safety_guard-99e.11发现约85% 的 pack 规则可以用线性时间的regexcrate仅约15% 需要前瞻/后顾等回溯特性。CompiledRegex::new()会调用needs_backtracking_engine()做语法启发式判定自动为每条规则选择引擎若线性引擎编译失败还会回退到回溯引擎重试保证高级语法不漏配。正是在这种架构下ksk.8 任务提出疑问regex-automataRust 生态中由regex团队维护的更底层 DFA/NFA 引擎能否替代或补充现有双引擎获得更好的 ReDoS 抵抗力、统一 API 或多模式匹配优化于是有了 ksk.8.1 的可行性报告与原型基准docs/regex-automata-feasibility-report.md以及 ksk.8.2 的决策门即本决策备忘录 docs/regex-automata-decision-memo.md并最终在 docs/decision-dfa-backend.md 中正式关闭。基准测试设计对照实验的严谨之处可行性研究没有停留在纸面推演而是把regex-automata作为dev-dependency引入见 Cargo.toml 中regex-automata 0.4 # For ksk.8.1 prototype comparison并编写了专门的 Criterion 基准 benches/regex_automata_comparison.rs。这套基准设计有几个值得借鉴的要点使用真实业务模式从 dcg 各 pack 中抽取代表性规则包括git-reset-hard、git-clean-force、git-push-force、rm-rf、docker-prune、kubectl-delete、drop-table、truncate覆盖从简单线性模式到大小写不敏感模式。混合正反样本测试命令集既包含会命中的危险命令git reset --hard HEAD~5、rm -rf /var/log/old也包含应被快速拒绝的安全命令git status、ls -la专门检验快速拒绝路径。多维指标覆盖编译时间、单模式匹配is_match/find、多模式 pack 模拟顺序扫描 vs 组合交替、ReDoS 病态模式、长输入吞吐五个维度。使用black_box防止优化作弊所有输入均经过std::hint::black_box确保基准不会被编译器优化掉。关键基准数据全面解读五组对照结果1. 编译时间regex-automata 明显吃亏模式regexregex-automata差异git-reset-hard~4.8µs~6.8µs42% 更慢git-clean-force~4.5µs~6.2µs38% 更慢rm-rf~5.2µs~7.1µs37% 更慢drop-table~3.1µs~4.9µs58% 更慢regex-automata 的编译开销普遍高出 40%60%。虽然可行性报告指出 dcg 的LazyCompiledRegex模式OnceLock惰性编译每个模式只编译一次可以缓解这一劣势但编译开销仍会真实地体现在冷启动场景中——尤其是 hook 是一次性进程时。2. 单模式匹配几乎打平甚至略慢操作regexregex-automata差异is_match~47ns~48ns~2% 更慢find~49ns~52ns~6% 更慢两者都达到 sub-50ns 的匹配速度。结论是替换引擎并不会带来匹配性能提升。3. 多模式 Pack 模拟顺序扫描无优势场景regexregex-automata差异顺序扫描命中~75ns~78ns~4% 更慢顺序扫描未命中~312ns~318ns~2% 更慢组合交替模式~58ns~61ns~5% 更慢dcg 当前的 pack 评估方式是逐条规则顺序is_match两条引擎在这种工作负载下表现几乎一致。4. ReDoS 病态模式唯一亮点但意义有限模式regexregex-automata状态(a)$~15ns~16ns两者均 O(n)(a|a)~22ns~15nsautomata 快 32%(a*)*b~22ns~16nsautomata 快 27%这是 regex-automata 唯一取得明显领先的维度。但正如决策备忘录强调的regexcrate 本身基于 Thompson NFA已经提供 O(n) 保证两个引擎都能在 O(n) 时间内处理灾难性回溯模式因此这 27%32% 的差距属于锦上添花并非刚需。5. 长输入吞吐均远超预算输入大小regexregex-automata吞吐100 字节210ns201ns~520 MiB/s1KB1.48µs1.49µs~650 MiB/s5KB7.16µs7.16µs~665 MiB/s10KB14.3µs14.4µs~667 MiB/s两者在长输入上几乎一致稳定在 ~650 MiB/s 的吞吐水平远在 dcg 的性能预算之内。性能预算体系决策背后的标尺决策备忘录反复引用所有性能预算see src/perf.rs这并非虚指。dcg 在 src/perf.rs 中定义了分层性能预算表作为 CI 基准强制、运行时受限评估阈值与文档预期的唯一事实来源source of truth层级路径目标超过告警超过恐慌0Quick reject关键词快速拒绝 1µs 5µs 50µs1Fast path安全命令快速路径 75µs 150µs 500µs2Pattern match完整模式匹配 100µs 250µs 1ms3Heredoc 触发检测 5µs 10µs 100µs4Heredoc 内容提取 200µs 500µs 2ms5脚本语言检测 20µs 50µs 200µs6完整 heredoc 流水线 5ms 15ms 20ms此外hook 整体评估有1000ms 的绝对预算HOOK_EVALUATION_BUDGET_MS超时返回显式不确定indeterminate结果绝不会把不完整的分析静默转化为 allow。src/perf.rs 中还内置了大量测试如budget_documentation_matches_source_of_truth确保 README、AGENTS.md、CI 中的预算文案与代码常量保持同步防止文档漂移。正是这套预算体系让引入 regex-automata的成本一目了然即便匹配延迟只增加 2%6%其收益略微更好的 ReDoS 表现在现有 O(n) 保证面前毫无意义。现状评估dcg 已经不需要新引擎决策备忘录对现有实现给出的评估是满足所有性能预算基准定义见 src/perf.rsCI 有基准强制与回归检测99% 的命令在正则之前就被快速拒绝dcg 使用aho-corasick多模式字符串匹配构建关键词索引见 src/packs/mod.rs 中pack_aware_quick_reject与build_enabled_keyword_index对不含任何危险关键词的命令在进入正则阶段前就以接近 1µs 的成本放行对应预算表中的 Tier 0惰性编译摊薄模式编译成本LazyCompiledRegex见 src/packs/regex_engine.rs在包注册表初始化时只保存模式字符串OnceLock保证首次使用才编译、多线程竞争只编译一次显著改善允许路径的启动延迟已具备 O(n) ReDoS 抵抗力线性引擎 100,000 步回溯上限BACKTRACK_LIMIT双保险回溯超限时 fail-open 返回false/None见 regex_engine.rs 的测试test_pathological_backtracking_fails_open保证病态模式在亚毫秒内完成而非挂起数秒。值得一提的是即便是必须使用回溯引擎的 15% 高级模式dcg 也通过BACKTRACK_LIMIT 100_000将最坏情况评估时间限制在约 1ms 内现代硬件约 10ns/步正好落在PATTERN_MATCH预算的 panic 阈值内。成本收益分析为什么结论是不采纳性能结论决策备忘录核心表指标当前regexregex-automata结论匹配延迟~47-49ns~48-52ns无收益慢 2-6%Pack 评估~75-312ns~78-318ns无收益慢 2-4%ReDoS 模式~15-22ns~15-16ns轻微收益无意义编译~4-5µs~6-7µs更差慢 40-60%两个引擎都已提供 O(n) 保证因此 ReDoS 改进可以忽略不计。维护成本决策备忘录评估因素影响评估第三个正则引擎高增加CompiledRegex枚举复杂度特性开关管理中可选依赖增加构建矩阵复杂度模式分类中必须决定哪些模式用哪个引擎文档负担低需要解释更多引擎选项二进制体积当前发布二进制39 MBrelease、LTO、stripped预计增加 200-400KB2-5%与项目opt-level z的体积优化理念冲突。这一点在 Cargo.toml 中有直接印证release profile 采用opt-level z、lto true、codegen-units 1、panic abort、strip true全部为缩小分发体积服务同时为恢复正则编译速度专门对regex、regex-automata、regex-syntax、fancy-regex、aho-corasick等 crate 单独设置opt-level 3详见 Cargo.toml 中[profile.release.package.regex]等小节。这组配置说明 dcg 对二进制体积和启动延迟的敏感度极高——任何2-5% 体积的代价都会被认真对待。成本 vs 收益成本匹配慢 2-6%、编译慢 40-60%、二进制增大 2-5%、维护负担增加收益略微更好的 ReDoS 抵抗力不需要、统一 API不具说服力。结论不言自明。决策备忘录的最终定论是Do not adopt regex-automata at this time.当前不采纳docs/decision-dfa-backend.md 将其状态定为 CLOSED - DROP并明确指出关键发现——regex-automata 在所有实测操作上实际更慢而非更快唯一改进是病态 ReDoS 模式快 27%32%而两个引擎本就都是 O(n)。曾考虑过的替代方案与最终取舍可行性报告和决策文档共同梳理了三条技术路线Option A整体替换不推荐处处用regex-automata::meta::Regex替换regex。缺点是编译时间更高、丢失RegexSet优势——后者在 heredoc 触发检测中正被使用src/heredoc.rs 用regex::RegexSet实现单遍并行匹配对应预算表 Tier 3 的 5µs 目标。Option B混合方案曾推荐后否决保留现有架构仅对高频模式git-reset-hard、rm-rf 等使用预编译 DFA继续OnceLock惰性编译fancy-regex保留给 15% 前瞻/后顾模式。可行性报告曾建议谨慎推进但决策门评估后认为复杂度成本超过边际收益予以否决。Option CRegexSet 优化留待未来利用多模式匹配构建单个 DFA 一次扫描替代顺序评估潜在 3-5 倍加速——但决策文档明确指出该路线可以独立于 regex-automata 探索不构成现在引入依赖的理由。未来重新评估的触发条件决策不是永恒的。备忘录明确列出四条回访触发条件供后续维护者判断何时应重新打开这个议题性能回归若 pack 评估超出预算当前目标 ~100µs多模式优化若 ksk.8 Option C 的 RegexSet 方案出现显著收益依赖整合压力若fancy-regex被弃用或停止维护体积约束放松若分发约束放宽二进制体积不再关键。docs/decision-dfa-backend.md 中还补充了若 regex-automata 新版本获得显著优势或多模式匹配成为瓶颈也应重新评估。行动项与基准复现决策备忘录给出的行动项保持regex-automata仅为 dev-dependency仅用于基准对比生产二进制不受影响以本决策文档关闭 ksk.8.2考虑将 ksk.8 父任务标记为 deferred归档基准代码于 benches/regex_automata_comparison.rs供未来参考。复现这套基准的命令来自备忘录附录与可行性报告# 运行 regex vs regex-automata 对比基准 cargo bench --bench regex_automata_comparison # 验证当前性能满足预算 cargo bench --bench heredoc_perf # 运行 E2E 回归测试 ./scripts/e2e_test.sh其中heredoc_perf基准benches/heredoc_perf.rs覆盖 quick reject、fast path、heredoc 触发/提取、语言检测与完整 heredoc 流水线与 src/perf.rs 中的预算表一一对应是验证 dcg 性能健康状况的主要手段。结语一次教科书式的不换引擎决策回顾整条决策链可行性研究用严谨的对照基准给出数据 → 决策门基于性能预算、维护成本、二进制体积三维评估 → 最终以 DEFER/DROP 收官并把触发条件与基准代码完整归档。这个案例对任何正在做依赖选型的团队都有参考价值当更先进的引擎在真实工作负载上既不更快、也不更小、还更复杂时保守维持现状并用文档固化决策本身就是一种高质量工程决策。而 dcg 用aho-corasick关键词快速拒绝、LazyCompiledRegex惰性编译、BACKTRACK_LIMIT回溯上限与分层性能预算已经构筑了一条足以支撑 sub-50ns 匹配、~650 MiB/s 吞吐的正则防线——这正是它敢于对 regex-automata 说不的底气所在。【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考