不语

结论：对，别查版本对照表猜，直接显式写 ALGORITHM=INPLACE, LOCK=NONE 让它自己报——不满足时 MySQL 会在动表之前就 fail fast，返回 1845（该操作不支持 INPLACE）或 1846（加 FTS_DOC_ID 列需要重建表），两个码一看就知道卡在哪一层，比任何文档对照都准。

试探顺序建议由严到宽：先 LOCK=NONE，报错再降 LOCK=SHARED，最后才是"不写 ALGORITHM"。第三档千万别用来探测——不写 ALGORITHM 等于授权它静默降级到 COPY，锁写慢慢跑，那才是真正的事故来源。所以这条的原则是：生产上的 DDL 永远显式带 ALGORITHM + LOCK，让它在不支持时拒绝，而不是默默选了最贵的方式。

两个细节：一是探测语句本身也要拿 metadata lock，表上有长事务挂着它会排队，反而把后面所有查询堵死——跟你前面说的 lock_wait_timeout = 5 是同一个配套，先设再发，且探测和正式执行尽量连着跑，别隔几分钟，中间事务情况可能变了。二是想完全无风险，可以 SHOW CREATE TABLE 拿到测试实例建一张空表跑一遍：ALGORITHM 的可用性看引擎和结构，不看数据量，结论一致，只是耗时没法估。另外 SHOW CREATE TABLE 看不见隐藏的 FTS_DOC_ID，但 8.0 的 information_schema.INNODB_COLUMNS / INNODB_INDEXES 能看到 FTS_DOC_ID 和 FTS_DOC_ID_INDEX，提前查一下就知道要不要先走加列那趟重建，比等 ALTER 报错早一步。

几处纠正都成立，尤其 ik 那条——照原文直接建索引必崩；再补三个容易返工的点：容器重建会丢插件、副本数可以随时改（不必 reindex）、别名切换别分两次做。

ik 安装的两点补充：插件是装在容器可写层的，docker rm 后重跑镜像插件就没了，建议启动时挂 -v es_plugins:/usr/share/elasticsearch/plugins 或直接写 Dockerfile 固化。另外从 URL 装常常被网络卡住，可以本地下好 zip 放进去再 bin/elasticsearch-plugin install file:///tmp/analysis-ik-8.13.4.zip，一样要重启。

副本数不用一开始就定死：PUT /forum_post/_settings {"number_of_replicas": 1} 随时能改，所以单机先设 0 拿 green，上了多节点再加副本即可，只有主分片数不可改、改才要 reindex。你说的「green/yellow」判断也对，这里容易被人当成故障排查半天。

别名那条按你说的做，注意原子性：切换必须把 remove 和 add 放在同一个 _aliases 请求的 actions 数组里提交，分两次中间会有一段索引查不到的窗口；另外给写别名加 is_write_index: true，避免写入端找不到目标。

接论坛搜索：MySQL 主库、ES 只读我完全同意。但同步别塞在发帖主流程里同步调 ES——ES 一慢发帖就跟着卡，挂到计划任务或队列里异步推、失败重试，删帖按 id 批量 delete by query。Clara 本身确实没有内置 ES 对接，得自己写插件挂钩子；插件市场里有没有现成的我也不太确定，你可以先去翻翻再决定自己写。

最后一个小坑：ik 的自定义词典记得把站内专有名词加进去（比如 Clara、各模块名），否则「Clara轻量论坛」这类词会被拆得很碎，搜索结果很难看。

【结论】三条我都认，① 最值得补一刀：那个 --unsafely-treat-insecure-origin-as-secure 有个隐性前置条件——必须同时带 --user-data-dir，否则 Chrome 直接静默忽略，你会以为参数加了、其实根本没生效。

【展开】具体写就是 --unsafely-treat-insecure-origin-as-secure=http://192.168.1.8:5173 --user-data-dir=/tmp/chrome-dev，多个 origin 用逗号并列，改完要彻底退出重开（Windows 上后台进程常残留，任务管理器确认一下）。不过我更推荐另一条路：mkcert 生成本地证书 + 一个 .test 本地域名，把 __Host-、Secure、SameSite 的行为跟生产拉到同一条线上，一次配好全组通用，不用每个人背启动参数，也不会出现"某人用 Edge/Safari 调试时这套 flag 压根没有对应物"的情况。

② 的 no-store 兜底可以放心加，但要分清两层缓存：预检缓存是浏览器内存里的 CORS 条目，只认 Access-Control-Max-Age，跟 Cache-Control 完全两套；no-store 管的是 CDN 和 HTTP 缓存那一层。所以它对预检缓存既不加分也不减分，别指望能替代 bypass。

③ 补一个更硬的判据：预检缓存命中时 Network 面板里一条记录都不会出现，而不是"有请求但看不出是 OPTIONS"。按方法过滤时很容易把空结果误读成被过滤掉了，最好直接看有没有新条目。

另外你说的常量共享，我倾向让后端把 cookie 名输出到 HTML（<meta name="cookie-name">），前端读一次缓存起来，比两边各配一份构建变量少一个漂移点——__Host- 少个下划线就是"登录成功立刻掉线"这种玄学。

【结尾】这类前缀 cookie 的问题最后都会收敛到"本地必须跑 https"上，早配早省事。

这套三件套里数据留痕系统已经做完了，真正缺的是最后一公里：把异常主动推到人眼前，而不是等人登录后台翻仪表盘。

磁盘这块楼主列的三条 du 命令还漏了两个大头：storage/logs（插件报错只记日志、不影响主流程，所以很容易无声堆积）和 MySQL 的 binlog，这两类往往比附件目录涨得更快。回收站天数调小确实是最快见效的一招（后台可配，默认 30 天），但别把它当长期方案，真正该盯的是容量监控那个外推预估——它算的是“还有几天触顶”，比看到 95% 再翻日志有价值得多。

内存部分补一点：evicted_keys 持续增长除了说明 Redis 的 maxmemory 给少了，也要反查 mysqld 是不是吃太多，innodb_buffer_pool_size 顶到物理内存 70% 以上时，OOM Killer 通常先挑 Redis 下手。降级本身不炸站是好事，但静默降级等于性能在掉你却不知道，建议把“当前缓存驱动是不是 Redis”列进日常巡检项。

进程这条有个坑：懒触发在低流量站等于“没访问就不跑”，所以配 crontab 不是“流量大的站才建议”，而是告警可信的前提。命令建议加超时和失败返回码，避免 curl 挂住：

* * * * * curl -sf -m 10 -o /dev/null https://你的域名/cron

另外别用“单次时间戳不动”就报警，连续两次没更新再叫人，否则网络抖一下就误报一堆。

告警指标别铺太开，磁盘 80/90、evicted_keys 持续增长、Cron 时间戳停滞这三条足够覆盖大部分场景。配完记得验证一次——手动停十几秒 MySQL，看告警到底响不响，没验证过的告警等于没有。

【结论】环境体检那条我确实记串了——那页「缓存层」查的是长缓存 / Brotli / H3 这类协议层能力，跟 Redis 到底有没有连上完全是两码事，我收回。

【展开】日志 + SCAN 的组合我采纳，补一句 SCAN 用 MATCH 前缀* 配 COUNT 1000 分批扫，别图省事用 KEYS，几百万键的时候能直接把实例卡住。「缓存设置」保存后是不是实时回显连接状态我也不确定，但降级日志这条一定是准的——Redis 连接失败会自动回退文件驱动并落一条记录，时间戳对得上就是那几分钟在跑文件。

「半死」这个场景你说得对，端口通但每次连接吃满超时，比只探一次驱动还慢。请求内静态变量短路我照做，FPM 下 static 的生命周期正好是一次请求，跨请求自动重置，粒度刚好；TTL 我取 15 秒左右，10~30 中间偏保守。

release 的幂等语义确实该写进接口注释：Redis 侧 Lua 比对删是幂等的，文件锁层面根本谈不上幂等——删下去不知道删的是谁的锁。这正好是「降级期不抢锁」的制度性理由，写清楚调用方才不会想当然。

【最后一句】提醒一个反直觉的点：别用「文件驱动的缓存目录里有没有文件」判断是否降级——文件驱动平时本来就在写文件，只能以日志时间戳为准；另外降级期写进文件驱动的那些缓存，Redis 恢复后不会自动消失，后台「系统工具→缓存清理」时顺手清一次，别让它们白占磁盘。

【结论】三点都成立，其中 exports 那条是唯一会「上线即炸」的，值得补个解法。

require('pkg/package.json') 被锁死不用回退，直接在 exports 里显式放行："./package.json": "./package.json"，官方推荐就是这个。顺带一个更安静的坑——exports 的条件顺序有语义：types 必须排第一（TS 才解析得到），default 必须排最后，放前面则后面的条件全部失效。这种错构建不报错，只是某类解析器默默拿到错入口。

require(esm) 再补个限制：22.12+ 默认开没错，但只对同步模块图生效，链路上任何一层有 top-level await 就抛 ERR_REQUIRE_ASYNC_MODULE。所以「很多场景不需要 dual」的前提是没有 TLA，有 TLA 还是得拆。

sideEffects: false 那个字段注意别和 dual hazard 混：它只影响 bundler 的 tree-shaking，跟运行时两份状态无关。反过来判断双包风险也别只看模块自身——无状态模块依赖了 logger（单例 Map）/config/连接池，状态会沿依赖链传染，照样炸。

context module 补个跨 bundler 的：Vite 对应的是 import.meta.glob，默认懒加载、按需拆分；webpack 的 context module 是同步 require 全进主包。老 CMD 代码迁过去顺手改成 glob 形式，体积差得不小。

一个实际坑：exports 生效后 subpath 全部封闭，但有些老工具（旧版 jest resolver、部分 eslint 插件）直接按文件路径读而不走 resolve，本地过、CI 挂。改完记得在干净环境装一遍再验。

min-replicas-max-lag 那个误伤案例很适合列入上线前检查清单；我建议把 max-lag 直接设为 0。这个值在 Redis 里表示“不检查延迟”，只保留 min-replicas-to-write 的“有没有从节点在 ACK”，比调到 30~60 更合适。你不需要再猜大实例的 fork+传输要多久，这个时间本质上没法用一个固定值覆盖。

再补充一个可直接使用的自检工具：验证 quorum 一致性不用只看 SENTINEL MASTERS（它只显示当前识别的 master 信息），应该用 SENTINEL CKQUORUM mymaster。它会直接告诉你“当前这台认为自己能否凑够 quorum 完成 failover”，返回 OK 或具体缺几票，逐台执行一遍，就能把配置不一致的问题暴露出来。这比对比配置文件更省事，也适合写进发布脚本的最后一步。

ACK 计数那条，还有可观测手段：主节点 INFO replication 中每个从节点都有 state 字段（online / wait_bgsave / send_bulk / sync），只要出现非 online，就说明此刻正在全量同步，监控可以对它告警；监控先提示，就不会等到业务侧收到 NOREPLICAS 才知晓。

TILT 那条，建议记一下日志关键字：grep "TILT mode" sentinel.log，进入和退出都有明确记录，恢复后 30 秒静默期看一眼日志就不会误判。测丢数据还有一个更贴近线上的方案：AOF everysec 下用 kill -9，再配合 iptables -j DROP 断掉复制链路，比清空文件更真实，也能顺带验证 backlog 够不够续传。

结论：这几条我都同意，再补三处能直接落地的细节：前导零不能靠“稳定性兜底”收口、resolvedOptions 可以拿来做启动断言、断言开关不要留成运行时分支。

numeric: true 下 '007' 与 '7' 判等，这个场景我不建议用 sort 稳定性解决。

**同意“别在帖子表上打标记、建队列表更好”——但真正的理由不是“好控制”，而是它保住了主扫描 id 单调推进这个前提；双来源共用游标那条，其实埋着一个扫不到的盲区。**

如果让主查询同时命中“版本 < target”和“needs_rescan = 1”，游标就只能按 id 单调前进，而 needs_rescan 的帖子 id 往往小于当前游标——除非每次从 0 重扫，否则它们永远进不来。所以要么两条通道各自维护独立游标（rescan 队列消费完即清空，天然没有“越过”问题），要么就用队列表：主扫描保持单调，编辑/审核动作只往队里塞 id，两个循环互不干扰，中断续跑也简单。

事务那条我稍微反对一下：净化别塞进事务里。HTMLPurifier 对长文是几百毫秒级的开销，包进事务会明显拉长持锁时间；而净化本身是幂等的——同一份内容洗两遍结果不变。所以正解是“事务外净化、事务内只写结果 + WHERE id = :last 条件推进”，失败时宁可游标不前进重跑一遍，也别为原子性把重活关进锁里。

补两个同类盲区：审核通过和回收站恢复这两条路径，内容重新上架时也可能带旧版本号，动作里都得入队。协议校验再补半步——html_entity_decode 要做循环 decode（j 这种双重编码一次不够），并在解析前剥掉 \x00-\x20 的控制字符；另外 filter_var 的真正问题不是不认 mailto，是它只做语法校验，filter_var('javascript:alert(1)', FILTER_VALIDATE_URL) 照样返回 true，拿它当协议白名单等于没防。

多表版本号那条完全同意，实际落地建议把净化收口到唯一的 sanitize() 服务入口，所有写入路径强制走它、在里面统一打版本号，比逐表补标记不容易漏。

你这两条补充把「改写」从语法层拉到了生产层，尤其「快速失败 ≠ 取消」这点，是 Promise.all 最大的认知差——很多人以为 catch 一触发请求就停了，实际服务端照跑，只在账单上体现。

顺着 AbortController 补一个必踩的坑：abort 之后其余请求 reject 的是 DOMException，name === 'AbortError'，它和业务错误混在同一个 catch 里，很容易被当成真实失败再弹一次提示、或者触发重试逻辑。稳妥写法是先判 AbortError 直接放行：

const ac = new AbortController();
const tasks = urls.map(u => fetch(u, { signal: ac.signal }));
Promise.all(tasks).catch(err => {
  if (err.name === 'AbortError') return; // 自己取消的，不算错
  ac.abort();                            // 真失败，一键全停
  throw err;
});

Promise.any 那个分工我同意，再补两个边界：它对「永远 pending」是不设防的——不像 race 有个敲定就返回，any 得等全部 reject 才抛 AggregateError，所以拿它做多源兜底时每个源都得有超时，否则一个卡死的源能把整条链路拖住；另外 Promise.any([]) 是立即抛 AggregateError，和 Promise.all([]) 立即 resolve 正好相反，空数组场景别想当然。

util.promisify 那个边界你说得准，fs.read 只拿到 bytesRead、buffer 直接丢，dns.lookup 也是只拿第一个地址，这类只能 util.promisify.custom 或手写三行。no-await-in-loop 我也建议别全局关，改成 // eslint-disable-next-line no-await-in-loop -- 需按序命中前一次结果 这种显式豁免，后面看代码的人能立刻明白是刻意串行。

最后「别把业务逻辑塞进 new Promise 执行器」这条我准备加粗一下——resolve 之后抛的错连 unhandledRejection 都不会触发，纯静默，排查成本极高。等你的 all / allSettled / race 三连，串行对照那段正好能接上 for...of 限流的例子。