perf(core): Spring 索引正则改为只编译一次，491.74s 降至 2.40s

[Farewell0375]

修复 #299。

问题

在约 1 万个 Java 文件的 Maven 项目上，release 构建下 spring.index 耗时 648 秒。因为 reloadProjectServices 挂在工作区文件监听上，每批文件变更都会重新触发一次。

原因

不是扫描范围的问题，是正则在热路径上被反复编译。

bean_index 对每个文件的每一行无条件发生的编译：

调用	每行编译次数
has_annotation(&context, "Bean")	1
is_injection_context(&context)（Autowired / Inject / Resource）	3
constructor_regex(type_name)（在逐行循环体内）	1

命中类型声明的行再加 has_component_annotation 的 6 次和 has_annotation(&context, "Primary") 的 1 次。

按每行 5 次保底、数千个文件计，量级在一千万次左右。单次 Regex::new 约 60 微秒，乘出来正好是观测到的耗时量级。

改动

19 处固定模式改为函数内 static LazyLock<Regex>。 定义在使用它的函数体内，作用域不外泄，函数体其余部分不动。仓库中现有的 OnceLock 都用于 Mutex<HashMap> 这类可变缓存，属于另一种场景。

constructor_regex 提出逐行循环。 它依赖声明类型名，无法做成全局常量，但对同一个文件是不变的。原先在算 constructor_count 时编译一次，又在逐行循环里每行重新编译一次；现在每文件构建一次复用。顺带去掉了一层已经多余的 if let 嵌套。

has_annotation 改为查表。 这是最热的一处。本模块识别的 11 个注解名预编译进 LazyLock<HashMap>，未命中的名字回退到即时编译，这样将来有调用方开始识别新注解时不会静默失效。

扫描范围、遍历顺序、结果排序均未改变。 本 PR 只降低常数因子，不引入增量索引。

验证

性能。 在 dev860/Backend/Service（7774 个 Java 文件、10063 个快照文件）上，release 构建：

改动前  491.74 秒
改动后    2.40 秒

行为等价性。 同一份输入，改动前后各保存一次完整 spring.index 响应：

before.json  3519348 bytes  ca1d210f94d3207e869381b8a3a42b6ce27a2872c3a673f3ca736c66cc5b42d4
after.json   3519348 bytes  ca1d210f94d3207e869381b8a3a42b6ce27a2872c3a673f3ca736c66cc5b42d4
cmp → 逐字节相同

七类产出逐项一致：properties 16、values 327、propertyReferences 111、diagnostics 1870、beans 2338、injections 4479、endpoints 4103。这覆盖了单元测试触及不到的真实代码形态，包括排序结果。

脚本。

./scripts/verify-rust-core-comments.sh  通过
./scripts/verify-rust-core.sh           通过
./scripts/verify-core.sh                通过
cargo test -p lithe-core                264 + 5 全部通过

新增 spring_index_does_not_treat_longer_annotations_as_recognized_ones，用 @BeanFactory、@ServiceLocator、@RestControllerAdvice 三个诱饵锁住 (?:\s|\(|$) 的边界语义——如果有人把匹配改成朴素的 contains，这三个都会被误判成 bean 或控制器。

已执行 cargo fmt。

关于增量索引

issue 下有评论认为成因是"没有做增量索引而是每次都走全量"。全量重跑确实存在，但它决定的是重跑频率，不是单次耗时：本 PR 没有改动扫描范围，仍然是全量，单次仍从 491.74 秒降到 2.40 秒且输出逐字节一致。

增量在这里也不是小改动。bean_index 先扫描全部源码建立全局 supertype 映射，再拿所有 bean 解析每个注入点；改一个文件会影响其他文件的解析结果（例如新增 @Primary 会改变别处所有歧义注入的结果）。朴素的按文件增量会产生错误结果，需要配套依赖追踪。建议作为独立议题评估——单次成本降到 2.4 秒之后，其收益已大幅下降。

不在本 PR 范围内

annotation_context 每行构造 Vec<String> 并 join 的分配开销没有处理。前述改动之后总耗时已是 2.4 秒，进一步优化收益有限，且会在缺乏证据的情况下改动一个工作正常的函数。

[1lck]

改动方向和当前行为等价性没有问题，但这里仍有两处会增加后续维护和性能回归风险的设计，请处理后再合并。

[1lck]

@Farewell0375 你好 以上是一些pr阻塞点 麻烦处理一下哦 如果您有一些其他好的方案也可以在此PR下与我讨论

[Farewell0375]

@1lck 感谢评审，两条 [Important] 都已处理，e8d8838c。细节回在对应批注下了，这里总结：

注解识别 — 引入封闭的 SpringAnnotation 枚举，模式表由 ALL 构建，即时编译的 fallback 已移除。调用方只能引用 case，新增注解漏掉 name() 的穷尽 match 会编译失败。component_name 的候选集也改为从 COMPONENTS 生成，不再重复罗列。

重复模式 — 两处一字不差的 Java 参数声明正则合并为模块级 JAVA_PARAMETER_DECLARATION。

行为等价性重新验证。 在 dev860/Backend/Service（7774 个 Java 文件、10063 个快照文件）上重跑完整 spring.index，与最初基线逐字节比对：

改动前              3519348 bytes  ca1d210f...cc5b42d4
本 PR 上一版        3519348 bytes  ca1d210f...cc5b42d4
本次评审修改后      3519348 bytes  ca1d210f...cc5b42d4

三轮 SHA-256 完全一致，2338 个 bean、4479 个注入点、4103 个端点逐字节相同。耗时 2.67 秒（基线 491.74 秒）。

验证：verify-rust-core.sh、verify-rust-core-comments.sh、verify-core.sh、测试稳定性门禁全部通过；cargo test -p lithe-core 267 个测试通过（新增 3 个）。已跑 cargo fmt。

关于 issue 下"没做增量索引"那个推测，我在 PR 正文里放了一节说明：本 PR 未改动扫描范围，仍是全量，所以单次耗时的成因是逐行的正则重复编译而非全量本身。增量因为 bean_index 的跨文件 bean 解析语义需要依赖追踪（改一个文件会影响别处的注入解析），朴素按文件增量会出错，建议作为独立议题评估。

[1lck]

前两条建议已经确认修复并关闭。这里还有一个需要补的点，见行内评论。

[Farewell0375]

更正：先前留言说「已关联并关闭 #299」不准确。#299 已重新打开，是否关闭等维护者确认后再定。#306 与 #299 的交叉引用仍在。