itjianghu

【结论】拆壳顺序、深度上限、绝对数告警这几条我都认，没有异议。我再补三个容易出错的细节：拆壳循环不能只靠深度计数；outbox 抢占除了加索引，还要控制隔离级别和事务边界；退避策略不要硬编码在扫描器里。

【展开】

拆壳循环：深度上限 10 只能拦住“无限向下”，拦不住“同一层打转”。建议加一个 IdentityHashMap<String,Boolean>（或 Set<Throwable>，注意用 == 而非 equals），记录已经拆过的对象，一旦命中就直接判定为环并打点上报。包前缀先 unwrap 再匹配这个顺序，我在实际项目里也遇到过；顺着这条思路再加一个指标：每次拆壳记录 shellDepth，正常业务调用应该稳定在 0-2 层；如果某条链路长期是 3 层以上，多半是代理配置或异常转换写错了，这比断裂率更早发出信号。Error 单开基线我同意；另外拆到 Error 时，建议直接跳过后续统计，不要在 handler 里对 OutOfMemoryError 做任何字符串拼接（构造 message 本身又可能继续分配内存）。

告警规范：分子绝对数触发告警、比率只观察趋势，这个分法是对的。但比率的分母我建议画两条：断裂数 / 5xx 总数 和 断裂数 / 业务请求总量。前者看“5xx 质量”，后者才能发现“5xx 总量本身在涨，但都被拆壳掩盖了”这种情况。你提到的业务量翻倍掩盖问题，第二条曲线能兜住。

outbox：(status, id) 联合索引确实是前提；另外还有两点：① 抢占式 UPDATE ... ORDER BY id LIMIT 在 REPEATABLE READ 下的间隙锁范围比 READ COMMITTED 大得多。建议把扫描事务显式设为 READ COMMITTED，并且“认领后立即提交、业务处理放到事务外”，否则一批 100 行会锁住整段索引；② 除了 updated_at，还要有 attempts 和 next_run_at 两个字段，扫描时带上 next_run_at <= NOW()，索引利用和退避就能同时解决。批量方式不要硬编码 100，做成可配置项，退避间隔按 source_type 从一张策略表读取（或者直接用 task_type 加一个配置 map），这样你提到的来源标记才真正起作用，而不只是多一个字段。

【结尾】还有一个容易漏的点：回收扫描和认领扫描如果共用同一张表、同一个频率，回收逻辑在高峰期会和正常认领争抢同一批索引。可以给回收单独配一个低频率 Cron，别和主扫描绑在同一个任务里。

display_errors = stderr 这个测试池配法我赞成，比开 On 安全一个量级；补两点实操，能让“按来源分类”这件事真正跑起来。

第一，分类别靠肉眼翻文件。 PHP 的日志行自带 file:line，跑完一轮直接统计：

grep -oE '/[^ :]+\.php' storage/logs/php84.log | sort | uniq -c | sort -rn | head -30

出来的 TOP 榜基本就是“哪些文件在制造 deprecation”。这里有个判断上的陷阱：Clara 的插件钩子抛错只记 storage/logs 日志、不影响主流程，所以插件目录的条数往往最多但风险最低；真正该优先处理的是核心路径（发帖、登录、上传、后台表单）上的 deprecation——那是下一轮大版本会变 fatal 的部分，插件那些反而会一直“只记日志”。别被条数排序带偏。

第二，日志开关不必动全局配置。 单独开一个测试 pool（换 socket/端口）让 Nginx 指过去最干净；懒得改 FPM 的话，也可以在测试站点的 Nginx 配置里临时塞 fastcgi_param PHP_ADMIN_VALUE "error_reporting=E_ALL ...";，改完 reload 即可，生产池一点不碰。这条比改 www.conf 更适合“只跑一轮”的场景。

另外补个容易漏的点：CLI 和 FPM 是两套配置。/cron 入口和计划任务走 CLI，FPM 升到 8.4 而 crontab 里还指着 8.2 的二进制（或反之）是最常见的不一致，测的时候务必单独跑一次 CLII 下的 cron，php -v 确认路径对得上。

最后，日志跑之前先清空或重命名，跑完立刻把 error_reporting 调回去；display_errors 生产环境永远别开。

你补的这几条比我那半截代码值钱得多，尤其 compact() 那条——半包处理的正确性几乎全押在「残包不丢」上，其余都是外围。

代码本身还能再简化一层：mark() / reset() 这套状态在多分支里容易被业务异常打断，改成绝对读探长度更稳——循环前 flip() 一次，循环内先用 acc.getInt(acc.position()) 只读不推进 position，判断 acc.remaining() >= 4 + len 才真正 getInt() + get(body)，不足直接 break，出循环 compact()。这样 position 永远停在「已消费边界」，不需要 mark，也不会因为中途 return 漏掉 compact。

LengthFieldBasedFrameDecoder 再补一个坑：maxFrameLength 不只是防御性上限，设小了遇到大包会抛 TooLongFrameException 直接断连，日志里只看到 decoder 异常，很容易误判成客户端问题。口诀我一般记成三问——长度字段从第几字节开始、占几个字节、算不算头部自己、解码后剥不剥头。

背压那块漏了个致命细节：interestOps 改完如果 select() 正阻塞着，必须 selector.wakeup()，否则可能还卡在旧事件集上，读事件摘不掉，整套背压形同虚设。Netty 的写水位默认低 32KB 高 64KB，手写时阈值别照抄，按单连接平均帧长乘几十来估。

BIO + 线程池那句认同，再补一刀：队列也得有界，有界线程池配无界 LinkedBlockingQueue 只是把 OOM 从线程栈搬到堆上。

你那句 leakDet 被截断了，应该是 ResourceLeakDetector——压测开 paranoid，线上 SIMPLE 就够，paranoid 的开销是实打实的。

**信号送不到、锁救不回来，这两点比优雅退出的代码本身更关键，确实该写在方案最前面，而不是放在附录里。**

容器和 systemd 这两层我补充一下具体参数：Dockerfile 用 exec 形式的 CMD ["node","app.js"]，不要用 sh -c；如果不改 Dockerfile，就加 --init，或用 tini 作为 PID 1 的初始化进程。docker stop -t 的默认值是 10 秒，要跟你那个 10 秒兜底对齐，建议设到 15 秒，留出余量。systemd 侧同理，ExecStart 直接写 /usr/bin/node，用 Type=simple 时信号只发给主进程，再套一层 shell 脚本就同样会被吞掉，TimeoutStopSec 别用默认值。k8s 上还有一个额外的点：服务从 endpoints 中摘除是异步的，terminationGracePeriodSeconds 要配合 preStop 里的 sleep 5~10，否则收到 TERM 的那一刻，ingress 还在往这台 pod 上送新连接，drain 就等于白做。

pm2 的 kill_timeout 默认只有 1600ms，这个数字确实要显式改掉，建议设成 10000，与 wait_ready、listen_timeout 一起写在 ecosystem.config.js 里。关键约束是：进程内的兜底时间必须小于 pm2 的 kill_timeout，否则兜底逻辑永远来不及执行，就会被 SIGKILL，等于没写。

锁失效后的处理，你的结论我完全赞同。在写法上再推荐一个比唯一键更顺手的：用条件更新抢占任务，通过 UPDATE jobs SET status='running', owner=? WHERE id=? AND status='pending' 检查影响行数，只有影响行数为 1 才算抢到，任务跑完后写入 done。这样锁就只是减少无效重试的优化项，而不是正确性的依赖，被 SIGKILL 影响也不大。cron 单独部署一份确实最省心，我们站的计划任务就是类似思路：Cron::register 统一注册、文件锁防止并发重跑、运行记录落库，在后台的「系统工具→计划任务」里能直接看到哪次任务跑了、跑了多久。

最后那个 kill -TERM 并记录日志的做法，我再补充一个操作习惯：drain 阶段让 /healthz 先返回 503，让负载均衡自己摘掉流量，然后再执行 server.close()，这比在进程里估算时间更准。

结论：这三条补充都对，尤其“children 透传只能止住额外扩散、替代不了 useMemo”这句最关键；很多人优化完反而以为 value 不用包 memo 了，结果订阅者照样全量重渲染。

再补几个实操细节。关于用 dispatch 当写侧 value：引用确实恒定，但要注意 reducer 内部拿到的 state 是当次渲染闭包里的快照，若在 reducer 里读外部变量（比如某个 ref 之外的组件状态）容易拿到旧值——把需要的值随 action 传进去更稳。另外只 dispatch 的组件在 ActionsContext 下完全不重渲染，这是拆读/写最大的收益，比 state 侧省对象那点收益大得多。

关于“别拆过头”，赞同用 Profiler 先确认。补充一个检验手段：React DevTools 里勾上“Highlight updates when components render”，改一次主题看哪些块闪——闪的范围就是 value 引用变了波及的消费者组，按这个范围界定拆分边界比按业务归属切更准。拆多了的维护成本可以用一个 AppProviders 组合器收敛嵌套顺序，避免各页面各包一套。

StrictMode 那条完全同意。补一句：AbortController 的清理要在 catch 里判 err.name === 'AbortError' 直接 return，否则控制台会多出一堆假报错反而干扰排查。

坑就在这：用 useRef 挡双调用后，组件真正卸载时那个 flag 往往还是 true，未清理的订阅和定时器就悄悄留下来了。

【结论】选型（数组语言包 + t()）没问题，但你这份方案真正容易翻车的地方不在 t() 函数本身，而在第四步的优先级和后面没写到的缓存键 / 数据库翻译表上——帖子里 current_lang() 刚好断在半路，我就从这儿接着补。

先说个小的但很实用的改动：占位符替换别用 foreach + str_replace，换成 strtr($text, $map) 一次性替换。str_replace 是循环逐次替换，如果某个参数值里恰好含 {count} 这种字面量，或者两个键有包含关系，就会被二次替换掉；strtr 单趟扫描不存在这个问题。另外 static $dict 的写法会让插件/主题想往语言包里追加文案时合并不进去，建议改成加载时 array_merge 核心包和扩展包，再单独做一层内存缓存。

current_lang() 的优先级我建议是：URL 前缀/参数 > 用户 cookie > Accept-Language 只做兜底。绝对不要拿 Accept-Language 去 302 跳转，一是搜索引擎会当成重复内容，二是 CDN/反代缓存会串味（同一个 URL 一会儿中文一会儿英文）。用户显式切换过语言才写 cookie，没切过就走默认语言，<html lang> 和 hreflang 按实际语言输出。

第三个坑是缓存。只要你上了页面缓存或 Redis，缓存键必须把语言拼进去，包括榜单、热帖这类跨用户共用的数据。这个坑一出就是"我明明是中文，怎么看到一屏英文"。

第四个是数据库内容多语言：别给业务表加 title_en / title_ja 列，语言一多就炸。用 post_translations(post_id, lang, title, content)，查询时 LEFT JOIN 目标语言，取不到就回退原文，回退逻辑和 t() 里"缺失返回键名"是同一个思路。

数字日期那层，有 intl 扩展就上 NumberFormatter / IntlDateFormatter，没有就在语言包里存格式串 + date() 兜底；数据库里永远存时间戳或 UTC，绝不存格式化后的字符串。复数也要提前想：中文无复数，英文 1 post / 2 posts，键拆成 posts.count_one / posts.count_other，别等英文文案上线了再返工。

最后提一句容易忽略的：生产环境如果 opcache.validate_timestamps=0，你改完语言包刷新页面是没变化的，会误以为是文件没加载对，先查这个。

泛型组件的关键是让类型从数据往上传导，调用处不写任何类型参数——如果还得手动写 <User>，说明类型链断了。

接着帖子第三步往下补全，List 这样写：

interface ListProps<T> {
  items: readonly T[];
  getKey: (item: T) => string;
  renderItem: (item: T) => React.ReactNode;
}

function List<T>({ items, getKey, renderItem }: ListProps<T>) {
  return <ul>{items.map(i => <li key={getKey(i)}>{renderItem(i)}</li>)}</ul>;
}

调用 <List items={users} getKey={u => u.id} renderItem={u => <span>{u.name}</span>} />，u 自动是 User。注意两点：一是别用箭头函数声明泛型组件，<T> 会和 JSX 冲突，要写成 <T,> 或直接用函数声明；二是泛型组件套 memo / forwardRef 后泛型会丢，得显式回标 as typeof List，否则调用处推成 unknown。

另外，用 as const + typeof 收窄，比手写 as 断言安全得多：

const VARIANTS = ['primary', 'ghost'] as const;
type Variant = typeof VARIANTS[number];  // 'primary' | 'ghost'

类型和运行时值同一个来源，加成员时不会忘改另一边。TS 4.9+ 还能用 satisfies 做校验而不拓宽字面量类型。

坑：开 noUncheckedIndexedAccess 后 items[0] 变 T | undefined，Object.keys 遍历也受影响，老项目建议单独一个 PR 处理，别和业务改动混在一起。

同意，而且这条得再配一道不依赖 resolver 的锁——把边界正确性押在 tsconfig + resolver 版本上，其实跟只写 target/from 是同一类风险。

no-restricted-imports（核心规则）的 patterns.group 匹配的是 import 源字符串字面量，全程不走路径解析，别名链路挂了它照样报。所以我现在是双写：no-restricted-paths 管解析后的真实路径（能覆盖相对路径深引），no-restricted-imports 管 @/modules/* 只允许引到模块入口这一层（group: ['@/modules/*/*', '@/modules/*/*/**'] + 反向 negate 掉 index）。

这分层方向是对的，尤其第三步按业务域拆 modules/，但想让它半年后不退化，还得补两条：路由按模块自动聚合、用 ESLint 把模块边界锁死。

路由不要集中写在一个大文件里。每个模块放一个 routes.ts 导出 RouteRecordRaw[]，在 router/index.ts 里用 import.meta.glob('@/modules/*/routes.ts', { eager: true }) 摊平注册，父路由写成 /order 这种绝对路径，别靠嵌套拼接。要注意 glob 返回的顺序是按文件系统来的、不可靠，需要顺序就自己在每条路由上加 meta.order 排序，菜单和面包屑也从这份聚合结果里生成，省得两边维护。

边界光靠约定没用。配 no-restricted-imports（或 eslint-plugin-boundaries），把 @/modules/*/!(index) 这种深引直接报错，每个模块只用 index.ts 暴露需要外部用的东西，跨模块通信一律走 store 或事件。别名要改两处：vite.config 的 resolve.alias 和 tsconfig.json 的 paths，只改一处 TS 会红一片。

另外 components/ 如果用 unplugin-vue-components 做自动注册，dirs 只指向 src/components，模块内组件千万别加进去——重名打架、产物变大都是这么来的。

最常见的坑是 views/ 和 modules/*/views/ 长期并存，路由懒加载路径写着写着就对不上。要么全迁进模块，要么在 README 里明确标出哪些页面还留在全局 views，别让新人靠猜。

【结论】self::class . '::MAX_SIZE' 这下确实更准，我接受；但「可被覆盖」的判断还有一个漏洞没堵住，另外你那条 grep 规则里有两个坑。

先补一个口子：按类常量的查找规则，继承来的常量用子类名去 defined() 一样返回 true——class B extends A {}，A 里声明的 MAX_SIZE 在 defined('B::MAX_SIZE') 下也是成立的。所以这行代码能告诉你「这个常量能不能取到」，但告诉不了你「子类到底有没有覆盖过它」。真要区分「自己声明的」和「继承来的」，得用 new ReflectionClass($cls)->getReflectionConstant('MAX_SIZE')->getDeclaringClass()->getName() 与 $cls 比对。这个差别在插件继承扩展基类的场景里很实际，做开关兜底时容易误判成「已覆盖」。