wbcm

你对 equals 那条的补充是对的，而且它比前面几个都更容易踩：StringBuilder 没有重写 equals/hashCode，sb1.equals(sb2) 比的始终是引用，所以拿它当 Map 的 key，或者把它塞进 Set 去重，基本都不会按预期工作。

setLength(sb.length() - 1) 在空列表上的边界确实成立，空列表时会直接抛出异常；我一般要么先判断长度，要么一开始就改用 String.join，不给尾部多出来的分隔符留隐患。

复用 builder 那条我补充一点：ThreadLocal 不是无条件的解决办法。在 Web 的线程池里，线程是长期存活的，ThreadLocal 里挂着的底层数组同样会常驻，而且如果请求里的异常路径没走到 setLength(0)，下一个请求会接着上一次的残留内容 append，比并发 bug 还难查。真要用，就在 finally 里 setLength(0)，并且在过滤器收尾时 remove()。所以我也倾向你说的：只在方法内的局部变量里复用，并保证结果长度可控。

另外，容量估算在 JDK 9+ 还要再打一层折扣：String 内部换成了 byte[] 加 coder（Latin1/UTF16），纯 ASCII 时按字节算刚好，一掺中文就翻倍，按 list.size() * (avgLen + 1) 估容易偏小。顺带说，你说的“老说法过时”还有一个例子：JDK 7 起 substring 已经改成复制新数组，不再共享原数组，早年的“substring 导致内存泄漏”如今也不成立了。

最后，JMH 那条提醒的时机很对，手写计时循环在 C2 下确实很容易测出假数据。

【结论】owner 校验思路对，但在池化环境里它抓不住最该抓的那种错误——线程池复用同一个 Thread 对象，任务 A 借的许可被任务 B 还回来，owner == Thread.currentThread() 依然成立，校验静默通过。

【展开】要把"谁的许可"真正编码进去，绑的不能是 Thread，而是一次租期：门面里给每个 Permit 生成一个单调递增的 permitId，acquire 时写进一个 ThreadLocal<Long> 当前上下文（或用任务上下文对象显式传），close 时比对的是 permitId 而不是线程。代价是要在任务入口设/清上下文，但这是唯一能区分"同线程、不同任务"的办法。如果不想引入上下文，退一步：开发态直接用 -ea 断言 + 单测覆盖，把跨线程归还挡在测试阶段，生产只留计数。

另一个小矛盾：你 close 里 throw IllegalStateException，和大家说的"close 别抛异常"是打架的。实际影响是——业务块正常时 ISE 直接抛出，符合预期；业务块本身抛异常时 ISE 会进 suppressed，主异常保留但这条跨线程信号被压掉了。所以跨线程归还至少要同时 log.warn 一份（纯内存计数即可，别在 close 里做 IO），否则日志里永远看不到。

【补充】门面顺手把数量记进去：Permit 存 permits 字段，close 时 release(permits)，这样 acquire(3) 就不会被人习惯性还成 1 个，漏还也一并治了；transferTo() 建议实现成 owner = newOwner 的可变字段（volatile），并在 transferTo 里做一次 CAS 防并发双移交。

【结尾】这套门面最好配三条单测锁死：异常路径仍归还、二次 close 不虚增、跨线程归还抛错——不然半年后有人"优化"一下就全白做了。

【结论】一个插件一个进程这个隔离思路是对的，但「注掉插件 handler 让日志回到原生格式」这一步我不建议做,至少不该作为默认做法——它会把你要测的东西改掉。

【为什么】

插件注册 set_error_handler 本身也是兼容性面的一部分。8.4 下很多 deprecation 就是由 handler 自身的签名或内部实现触发的(handler 的 $errno/$errstr/$errfile/$errline 形参、内部再调 error_reporting() 之类的写法)。你把这段注掉,日志格式是统一了,但等于把这批问题从测试轮里摘出去了,后面上生产再打开,一堆新警告冒出来——而且这时候你已经没有干净的对照基线了。

更稳的替代:让 handler 保持启用,但给日志行加个固定前缀(测试轮里临时改 handler 的格式串),比如 [PLUGIN] ... in /path on line N。这样原生行和插件行用同一个 sed 正则都能吃,靠前缀区分来源,uniq -c 也不会混。或者干脆两路都留:插件 handler 照常写自己的日志文件,原生 error_log 单独一个文件,统计时分两次跑。

【进程隔离那段的补充】

子进程方案里有个细节容易漏:核心类加载本身也可能抛 deprecation(比如核心 bootstrap 里的隐式可空参数),这类会写进每个子进程的日志,几十个插件跑完就是几十条重复。统计时按 插件名 分组之前,先把「每个子进程都出现过的行」减掉,剩下的才是该插件独有的问题。简单做法:先空跑一次只加载核心不 require 插件,拿到基线行集合,后续结果做差集。

exit code 判据之外,建议再抓一次 stderr 里的 Fatal error——有些声明期错误 PHP 会以 exit 255 退出但 stderr 内容被 shell 循环吞掉,2>&1 记到单插件日志文件里最保险,不然「跑完没报错」可能就是没输出。

【一句延伸】

这轮测完记得把临时前缀和开关全撤了再比对生产配置,php -i | grep error_log 和 php -m 各存一份跑前跑后对照,插件兼容性这块最怕的就是"测试环境干净、生产环境带着一堆临时改动上线"。

【结论】第一、三条我完全接，第二条想再收紧一下：单写者这个前提可以放宽成“写侧对打包字段做一次原子提交”，不一定非得 CAS。

一、写侧不必只用 CAS。 用 synchronized 写、volatile 读也成立：写侧持锁构造并发布，读侧无锁拿快照，竞争激烈时比 CAS 自旋省得多。CAS 循环真正的成本不只是重试，还有每次失败都要丢掉刚造出来的那个对象，GC 压力翻倍。我的经验排序是：写极罕见就直接用 volatile 引用替换；写偶尔有就锁写 + volatile 读；写频繁或要按索引原地改，再上 AtomicIntegerArray。

二、final 那条补一个省事做法。 JDK16+ 直接用 record 当包装对象，字段天然全 final、天然不可变，比手写 class 少一个漏加 final 的机会，正好堵住你说的那个“构造器里写入不受保护”的缺口。

三、CompileCommand 的坑再补两点。 加 -XX:CompileCommand=quiet 能抑制那条静默警告；方法名支持通配，不确定重载签名时写 类名::方法名 会匹配所有重载，写全签名反而容易漏。要维护多条的话放进 .hotspot_compiler 文件，用 -XX:CompileCommandFile 加载，比堆一长串命令行参数好改。

坑： -XX:TieredStopAtLevel=1 只跑到 C1，做对照实验够用，但别拿它下“生产环境也这样”的结论。C1 的循环优化和 C2 的常量提升不是一回事，结论会反。

结论：这三条修正都站得住，尤其“signal 只覆盖原生支持的异步源”这条——把 controller 当成统一清理器是最容易踩的误判，删掉原有 cleanup 后泄漏反而更隐蔽。

再说一个把第三方订阅也纳入 controller 管理的做法：const unsub = store.subscribe(fn); signal.addEventListener('abort', unsub, { once: true })。这样 abort() 一次就能覆盖，不用在 cleanup 里分别写两套。但有个隐蔽坑：在已经 abort 的 signal 上注册 abort 监听不会触发。如果订阅发生在 await 之后，等请求回来时 signal 早已 abort，那个 addEventListener 就静默失效了，清理永远不会跑。稳妥写法是先 if (signal.aborted) return unsub();，然后再注册。

关于“一个 effect 一个 controller”的粒度，我完全赞同你的这条界线。补充一个折中：一个 effect 内确实需要两个独立取消的异步源时，可以用 AbortSignal.any([a.signal, b.signal]) 合成一个“整体取消”信号，同时保留各自独立的 controller，既能让 cleanup 只写一次，又不会误伤长连接。

关于 ref 桥接，用 render 期写 ref.current 的方式在并发模式下确实危险，被丢弃的渲染会污染 ref。退一步的中间方案是：事件回调中需要的“最新值”根本不用 ref，改用 useReducer 的 dispatch（引用恒定、自带最新 state 语义），只有真正要读“上一次”的值（比如对比新旧筛选条件）才值得用 ref。实验性的 useEffectEvent 目前能解决这类问题，但稳定性还要再观察。

Profiler 那条我确认：不勾选“Record why each component rendered while profiling”，录制结果里确实看不到渲染原因；这一点和“Highlight updates”看到的闪烁范围一起用，定位才准。

全收，尤其「判等结果能不能直接存成状态」排在第一位这条——但我想再往前加一格：先问这个判等需求能不能直接消掉。

先回应你把 isDirty 放进 reducer 的取舍。它确实最省事，但隐含前提是写入口唯一：如果 draft 还有第二条写路径（表单 reset、服务端回填、异步落库后回写），isDirty 就成了第二份真相，两边漂移比漏 ++ 更难查——它不会静默失效，而是「看着对但偶尔不对」。所以「不需要维护纪律」得加个条件：纪律从散落各处收敛进了同一个 switch。这才是它真正优于显式键的地方，而不是「省掉一个键」。

因此我现在的取舍顺序是：能不判等 > 判等结果存状态 > 显式键 > 靠 identity。很多判等只是为了触发一次副作用或切一个渲染分支，能事件驱动就别比较——这一步砍掉的量比后面三档加起来都多。

useSyncExternalStore 那条补两个细节。一，它本身不带 selector，要 use-sync-external-store/shim/with-selector 那个版本才按 selector 结果做比较，否则 selector 每次返回新对象照样循环，只返回版本号也救不了。二，getServerSnapshot 我更怕的不是抖动而是 hydration mismatch——正确做法是返回模块级的初始快照常量，别在里面现算，现算的话接了 SSR 就是首屏报错而不是抖。

Stable 命名同意别提前抽。再补一句：名字里带「为什么稳定」比带「它稳定」有用，比如 useStableConfig，review 时能直接问出「这个 config 为什么必须稳定」，而不是只看到一个形容词。

纯透传那个信号我收下，它比「props 变多变少」好在 diff 里一眼能看出来，不用脑内推演。

结论：抢锁改成一条条件 UPDATE，我认可，这比“先 SELECT ... FOR UPDATE 再判断”少一个窗口；不过有两个边角情况需要补上：影响行数为 0 时，分不清是“别人占着”还是“这行根本不存在”；续租也不该按批推进，要按秒做心跳。

启动时先执行 INSERT IGNORE INTO scan_state (task_key, ...) 种一行。否则第一台机器执行那条 UPDATE 永远命中 0 行，日志里会出现“一直抢不到锁”的误导信息，排查半天才发现是种子行没写。另外，续租如果每批只推一次，在大文件场景下就不够用；建议改成每处理 N 条（比如 50 条）或每 5 秒推一次 lease_until，这样 TTL 才能压小到 3 分钟左右，而不是“两倍单批耗时”——后者在附件大小方差大的场景里根本估不出来，估大了进程被 kill 后要空等，估小了中途过期。

幂等这条我完全同意，唯一键建议用 (attachment_id, rule_code)，命中计数不要用 +1 累加，因为重扫会翻倍；只保存“最近一次扫描结论加批次号”，历史留给批次表就好。索引方面可以再推进一步：(status, updated_at) 里 status 区分度太低，隔离占比一高，优化器可能直接放弃走索引，最好补成 (status, updated_at, id) 覆盖索引，省去回表。

时区这一点要特别注意：TIMESTAMP 会跟会话时区转换，DATETIME 不会，两者混用必然出错。建议统一使用 DATETIME，在写入侧按 UTC 写入，并在连接建立时执行 SET time_zone='+00:00'。时间预算那条，不要依赖 set_time_limit，因为 FPM 下它不靠谱；在 chunk 循环里检查 microtime 后硬 break 才有效。

最后补一句你这句没说完的：单机确实自带文件锁，运行记录也能在后台「系统工具→计划任务」中查到；但那个锁是进程级 flock，在多副本或 NFS 上不能当真。因此租约逻辑还是得插件自己带，而且建议单机也走同一套代码路径，不要留“单机走系统锁、多机走租约”的双分支；单机分支跑顺了，上多副本时才会出问题。

常见坑：进程被 kill 时不要指望析构函数释放租约，只能靠 TTL 兜底，所以 TTL 宁短勿长。

【先给结论】你说得对，但比你说的更严重：把 ref 写入挪进 effect 之后，问题就不只是「configId 没变时永久停在旧值」，而是即使 configId 变了也会落后一拍：useMemo 在 render 阶段执行，effect 在 commit 之后执行，所以每次重算读到的都是上一次提交的 cfg，之后也不会再重算纠偏。

根因不在 ref 写在哪，而在依赖约定本身：memo 里读的是 cfg 的全部内容，deps 里给的却只有 configId，这二者本来就不是同一个东西。所以即使在 render 里写 ref，configId 不变时同样会命中缓存、读到旧值，只是 StrictMode 双调用偶尔会把它撞出来，看着像偶发。更糟的是 React 不保证 useMemo 缓存不丢，热更新或后续优化都可能把它清掉，于是这个 bug 时好时坏，最容易被当成缓存或接口问题查半天。

修法我倾向这三条：

1. 让 key 与依赖一致：deps 放能代表 cfg 全部内容的标量（configId + updatedAt，或调用方算好的 version/hash），并在开发环境加断言 if (cfg.version !== key) console.warn(...)，依赖约定被破坏时立刻暴露；

这几条我基本全收，尤其反向 zone 和 defineStore 那两条——真出事时的修复成本比模块互引高一个数量级。

no-restricted-paths 的 basePath 确实必配，我一般写 basePath: './src'，之后 target: './modules/order'、from: './modules' 才稳定生效。顺带提醒方向语义：target 是发起引用的一方，from 是被禁止的依赖来源，跟直觉正好反着，写反了规则会静默不生效还查不出来——配完随手在模块里加一行深引验证一下再提交。

反向 zone 我同意，公共层反向依赖是最隐蔽的一类。实操上除了加 zone，还得给个出口：把跨层契约提到 src/shared/contracts（或 types/），utils、components 只吃这里的类型，需要业务逻辑就靠 props/事件把数据传进来，别让 utils 反手 import { useOrderStore }。

vite-tsconfig-paths 那条补一下：分层配置时写 projects: ['./tsconfig.app.json']，另外它默认不跟随 extends，paths 写在被继承的 base config 里也读不到；改完必须重启 dev server，HMR 不重载插件配置。

route.matched 反查面包屑我采纳，只要 filter(r => r.meta?.title) 一下，把 layout 层那种无 title 的 record 滤掉，否则面包屑会多出一节空白。

defineStore 那条再强调一句：模块 index.ts 里只导出 useXxxStore 函数，绝不在模块顶层 const store = useXxxStore()——那等于把初始化时机绑定到首次 import，跨模块懒加载一交叉就全乱；要取数据一律在函数体内调。

【结论】“换说法再搜”归到写作侧这条我完全认同，而且它是这批动作里唯一不用等点击字段补齐就能开干的——但反喂词表要落在真能改的地方，别只存在运营文档里。

展开说：词表反喂发帖引导和版块置顶措辞，成本极低，但新帖标题能不能贴近用户说法，实际取决于发帖页有没有引导位。如果没有，可以先写进版规或置顶帖的示例标题里。老帖这边更好办：AI 长帖摘要是计划任务异步生成的，标题和摘要改完之后 meta description 会跟着更新，所以批量补一轮是可行的，确实比开版块低一个量级。

人工点结果页前三条的判断标准我接受，但得加个前提——搜索召回本身要靠谱。如果分词把本来存在的帖漏了，你点开前三条全空，会误判成“内容真缺”，其实是没搜到。试点时先拿自己确定存在的老帖标题搜一遍验证召回，再做判定，顺序别反。

会话串联这点我也同意：登录用户才准，游客 IP+UA 串起来噪声太大。在线会话是留痕的，但搜索日志里到底有没有能对上的会话标识，我不敢替你打包票，还是先翻字段再定口径。

子分类边界那条“看是否已在多个不相关版块零散冒头”我觉得可以直接当决策规则写进清单；摘标签先换入口位置再观察，比直接撤稳，这个顺序我认。

小坑单列一条：手机端入口这条值得单独列。单模板响应式理论上侧栏会折叠，但折叠到页面底部还是收进抽屉、会不会被埋掉，自己拿手机点一遍最快，后台配置看不出效果。