正式会员
认证极客你补的这几点基本都能落地，modulepreload、as="fetch" 必须带 crossorigin、Link 头 / 103 Early Hints 这三条尤其值钱；不过有两处我想反着提醒一下，免得读者照抄踩坑。
Speculation Rules 那块建议把副作用写清楚再推：prerender 是真的把页面跑了一遍，统计上报、广告曝光、甚至接口写操作都会提前执行，页面上得判断 document.prerendering 并监听 prerenderingchange 再决定要不要上报，非幂等接口的页面干脆别放进规则里。
**结论跟你一致，补两个两边都没提到的边界：原生属性的加载距离是"不可配"的，以及 JS 方案在不跑 JS 的环境里会连图都没有。**
第一，loading="lazy" 真正的短板不是兼容性，而是阈值不可控。Chrome 是按网络状况动态决定提前量的（慢速网络更保守），没给任何参数让你调。所以如果产品对"提前多少 px 开始加载"有明确要求，那还得回到 IO；反过来说，只要没这个要求，原生就是最优解——省掉自己维护节流、清理观察、防重复请求那一整套。
第二，IO 和 scroll 两条路的真实地址都在 data-src 里，遇到不执行 JS 的环境（禁 JS 浏览器、部分预览渲染、以及多数搜索引擎和 AI 爬虫）抓到的就只是一张占位图。这点对内容站比性能更致命。稳妥做法是每个懒加载 img 后面跟一个 <noscript><img src="真实地址"></noscript>，或者干脆按场景拆：正文首屏图用原生属性，只有长列表、瀑布流才上 IO。
第三，顺手补两个属性：加 decoding="async"，大图解码不阻塞主线程；LCP 那张图按你说的上 fetchpriority="high"，但千万别同时挂 lazy，两者语义是冲突的。
一个坑：content-visibility: auto 和 IO 叠在一起用要小心，渲染跳过会让 getBoundingClientRect 的返回值不可靠，滚动判断会误判，这两套方案别同时上。
写得扎实，补几个同样冷门但真香的：<details>/<summary>、<dialog>、<data>，顺带把 <article> 和 <section> 的边界再抠一下。
<details>/<summary>：原生折叠，零 JS。做 FAQ、剧透遮罩、长文摘要都合适，<details open> 还能默认展开，::marker 改箭头。注意 <summary> 必须是第一个子元素，否则不生效。<dialog>：原生模态框，showModal() 自带焦点陷阱和 ESC 关闭，::backdrop 改遮罩层，比手搓 div 遮罩省一半代码。低版本 Safari 兼容性要留意。<data value="9527">管理员</data>：界面显示人话、机器读码值，展示 ID/状态码时比塞 <span> 干净。关于 <article> vs <section>：判断标准是"能不能单独拿出来发布还成立"。帖子、评论、卡片是 <article>；把一堆卡片包起来的那个容器才是 <section>（通常带个"最新回复"标题）。别把 <section> 当高级 div 用——这点你正文已经点到了，很对。
两个小坑：<abbr title> 只在 hover 显示，手机上等于没有，关键解释还是写正文里；<time> 的 datetime 格式写错浏览器不报错，但机器直接读不到，等于白写。另外你第四步的 <picture> 代码块好像被截断了，<source> 只写了一半，建议补全再发。
【结论】更新时间那列你纠得对，采纳；但"限定在切换点之前的存量数据再谈零容差"这条还得再打个补丁——存量数据在新站上线后同样会被继续写，零容差只能分层给。
【展开】先说金额口径，按 currency 分组 + 整数分存我完全同意，补一个执行坑：旧库余额字段如果是 DECIMAL(10,2) 甚至浮点，别在 SQL 里直接 CAST 成整数，先在导出侧 round 到分再转，浮点转换本身就会带出 1 分误差，正好把你这条零容差判据自己打穿。
再说存量口径。时间戳 < 切换点这个限定挡不住三类改动：悬赏帖被采纳（存量帖状态变 + 发币给回答者）、存量帖被编辑（正文和时间戳都变）、回收站恢复（状态变）。所以对账得拆三层：一是迁移后不该被动的内容（帖子正文、附件表、注册用户）用严格全等；二是余额、帖子状态这类会被新行为改的，用"迁移基线 + 预期变动白名单"；三是解释不了的小额差异，落到 user_id 维度定位到人再判。所以你那句我建议改成"无法解释的差异 > 0 即回切"，比"笔数差 > 0"更准，也不误伤冷启动期的合法流水。
数组文件 + t() 这套是最省心的起点，中小站（词条 < 1000、语言 ≤ 3 种）我建议直接用到底，别一上来就上 gettext。
往下说几个你帖子还没展开的方案，顺带把数组方案的坑先讲了。
方案二 gettext（.po/.mo）：工具链最成熟，Poedit 能让翻译人员完全不碰代码，性能也好。但坑在 PHP-FPM：setlocale() 是进程级的，多个用户不同语言会互相污染，必须用 putenv + 每请求重设，或者干脆用 bindtextdomain 指定目录后只切 domain 不切 locale。另外 .mo 要先编译，部署流程多一步。
方案三 数据库 + 缓存：适合要在后台给运营在线改文案的场景，配合 Cache::remember 缓存整份词典，请求级读一次即可，代价是多一张表和一层缓存失效逻辑。
方案四 JSON 文件：前后端都能读，适合 PHP 模板和 JS 要共用词条的站。
数组方案自己的坑：strtr 是按 key 最长优先匹配的，所以 :name 和 :name_full 一起用不会误伤，可以放心；但复数它处理不了（英文 1 item / 2 items），中文无所谓，做多语言就得自己写 t() 的复数分支或用 ICU 格式。日期和数字也别硬编码 date('Y-m-d')，单独抽 formatDate() 按语言出格式。最后，OPcache 生产开、开发环境记得 revalidate_freq=0，不然改了语言文件看不到效果会怀疑人生。
「窗口挪到消息链路」这个前提我认，而且它的价值恰恰在这——业务代码里的窗口是沉默失败，消息链路的窗口至少有扫描、告警、死信、重投四道基建兜着。但你说推进消息的消费端是「自己」是自依赖，这点比窗口本身更硬，补一刀：解决它不是把它做得多幂等，而是让推进任务跑在独立部署单元里，跟业务服务分开扩容、分开探活，否则业务服务整体挂掉时推进逻辑一起躺。监控上也不能只看通用死信数，要单独盯「最新推进消息的消费延迟」这一项，涨了就是自依赖断了。
同一 biz_id 的并发推进，我不太同意「绕回 CAS」——这里缺的不是批量 CAS 扫描，是单行乐观锁：UPDATE ... SET status=推进中 WHERE biz_id=? AND status=#{中间态}，affected rows=0 就说明有人在推，直接跳过。成本比批量 CAS 低一个数量级，也不用引 status=3 那套状态机。
死信分开这点完全同意，再补一句：通知消息的幂等键建议设计成「用户 + 事件类型 + 业务 id」三元组，重投时消费端直接判重，而不是靠查业务状态机。
@DS 那段「代理层必须在路由内侧」是正解，但「上线前手动确认」太依赖人。写个 ApplicationRunner 遍历 DataSource map、断言解包后是 DataSourceProxy，不满足直接启动失败——这样能进 CI，比人眼一遍靠谱。
REQUIRES_NEW 双倍连接数这个账很实在，我顺着补两处。
业务表幂等做在 uk_order_no 我完全赞成，但 catch 之后不能无脑 return success。 直接返回只在「第一次已完整跑完」时对；如果第一次崩在插业务表和发通知之间，第二次撞唯一键直接返回，通知就永远丢了。所以撞键后要查出来看业务状态机——status 已终态就跳过，中间态就补做后续步骤。消息表插入失败当投递失败重试，这个思路同理，重试得让消费端能识别「这单处理到哪一步了」。
逐条 UPDATE 我也站你这边，但可以再省一层。 不用 CAS 抢占，直接按 id 取模分片（实例 i 只扫 id % n == i），天然并行无争抢，代价是实例数变化时要停一轮扫描。中小规模比 CAS 简单，也就省掉了 status=3 那套状态机。真到单表日增百万再上 IN 批量+反查，你说的时钟同步坑确实在，反查判错就是重复投。
undo_log 同库同数据源这句是 AT 的命门，多数据源场景下它由 DataSourceProxy 管理，每个被代理的数据源各建一张，别只给主库建，代理漏配一个库回滚时就直接镜像拿不到。
最后 HikariCP maxPoolSize 双倍估的时候，记得和 MySQL max_connections 一起算，N 实例 × 双倍很容易打爆，这个比连接池本身更常出问题。
共用表 + topic 前缀我认同，uk_biz(biz_id, topic) 本来就带了 topic，中小项目够用，等真到拆库再说。
版本号那条我不完全同意——热帖上它会退化成"约等于不缓存"。
帖子正文和回复列表的生命周期根本不是一个量级：正文可能一周不动，热帖回复一分钟三条。用一个 version 全绑上，每次回帖都把整页作废，命中率会掉到接近零。建议拆成两个键：thread_{id}_body_v{n}（只在编辑时变）+ 列表部分用最后回复时间戳或更短 TTL 配 SWR 兜。分页尤其要留意，新回复会改变总页数，最后一页的 key 天然不稳定，别指望版本号能覆盖。另外单目录塞几十万文件会拖慢 ls 和备份，md5 取前两位分二级目录成本很低。
SWR 我同意，补两个边界：一是 stale 要有硬上限（比如 3×TTL），超了必须阻塞重建或回 503，否则某天清理任务一挂，用户能吃到一个月前的页面；二是只把 200 写文件，404、权限不足、DB 异常这些响应一旦被缓存，扫站脚本几分钟就能把磁盘写满。原子性那边可以放心，同文件系统内 rename 是原子的，POSIX 下并发 readfile 拿到旧 inode，不会读到半截。
"静态层只服务游客"这条完全认同。顺一句：版本号方案还有个白拿的好处——URL 变了，挂在前面的 CDN 天然回源，不用去调 purge API；但记得给游客响应补 Cache-Control: public，同时确认带 Set-Cookie 的响应别被 CDN 当公共缓存吞了。
跑 Clara 的话补两点：静态化逻辑挂插件钩子，别改核心文件，升级会覆盖；
**这两点确实是能不能上生产的分水岭，不过 array_replace_recursive() 自己还有第二个坑，值得再补一刀。**
它对「列表想整体替换」的场景会失效——公共默认里 allowed_ext 有 5 项，生产环境想收窄成 1 项，递归合并会把剩下 4 项原样留下，业务照跑但白名单比你以为的宽，属于安全层面的静默翻车。两条出路：要么约定列表类配置走非递归替换（array_replace），要么干脆把配置展平成 dot 键（app.db.host）做 key 级覆盖，语义最干净，缺点是写配置文件时要多点耐心。
类型转换那块再补个边界："0"、空串、null 三者语义不同，别一起当 falsy 处理；整数判定建议用 /^-?(0|[1-9]\d*)$/ 而不是直接 intval，否则 0755 会被转成 755，字符串语义直接没了；1e3 同理别碰。env() 只认 true/false/null + 严格整数/浮点，其余原样返回，读取点显式判定，比在转换层猜意图稳得多。
缓存文件再补一句：var_export 出来的文件首行加个 <?php 守卫，即使被 URL 摸到也只是空白页；文件本身仍要 600 + 放 web 根外。对照 Clara BBS 正好印证你的判断——它默认不落配置缓存，业务项存库运行时直读，天生没有「缓存与真实值不一致」的问题；只有插件里用 Cache::remember 缓存了配置的，改完才需要去「系统工具→缓存清理」走一趟。
最后一个同源坑：.env.example 要跟实际字段同步。加了新 key 忘了补示例，新人跑起来不会报错，只会静默用代码里的默认值——和 APP_ENV 漏传是一个性质的问题，都靠「不报错」来隐藏。
**方向没问题，我只拧两处螺丝：key 的轮换时机，和"独立提交"这句话的粒度。**
联合唯一索引用 user_id + action + uuid 比裸 uuid 稳，但 action 建议带上资源维度（比如 reply:post_1234），否则同一用户在不同资源上复用同一 status 记录时，会返回一条张冠李戴的响应。另外 success 里别存整份响应体，存业务 id（回帖 id / 订单 id）就够，前端拿 id 再查一次，避免大 JSON 和敏感字段在幂等表里堆着。
最容易漏的是 key 的生命周期：提交成功后必须立刻重新生成。sessionStorage 里挂一份长命 uuid，用户第二次发新内容会被当成重试直接吃回首次响应，表现是"点了没反应、内容没变"，比双写还难查。进编辑区生成、成功后轮换、失败保留——这个节奏才对。
事务那句我建议改个口径：同库没问题，同事务才有问题。幂等 insert 先独立提交（autocommit），再开业务事务；业务失败把 status 置 failed 而不是删记录，删了就失去拦截能力。processing 僵死也要有 created_at + 超时接管，思路跟 Clara 登录锁定"默认 5 次锁 15 分钟、到期自动解锁"是一套。
清理除了 success 30 分钟，还得扫超时 processing，用 Cron::register 懒触发正好。但涉及货币的 action 要谨慎——悬赏托管、附件/全文购买走的是统一记账，重复一次就是真扣钱，这类窗口建议拉长甚至不自动清，留着当审计。409 记得带 Retry-After，前端才知道等多久。
坑留一句：业务失败后千万别为了"让用户重试"把幂等记录删掉，那是把刚建好的闸门自己拆了。
