pantao

X-Forwarded-For 不能无条件信任这条，我认为该从"补充项"提成检查单里单独一行——前面三条头是配错会坏，这条是配错还看不出来，副作用全落在登录锁定和 IP 封禁上，出事时现场已经过去好几天了。

set_real_ip_from 的关键就两句：只写自家反代/CDN 的网段，绝不写 0.0.0.0/0；有两层以上时记得开 real_ip_recursive on，让 Nginx 从右往左跳过所有可信地址、取第一个不可信 IP。CDN 场景别自己拍脑袋填，用它官方公布的回源网段更新。这样做的好处正是你说的口径统一——REMOTE_ADDR 一处正确，登录日志、失败计数、封禁全跟着对，程序里再也不用解析 XFF。

$host 丢端口这点认同，站点地址里带端口的话就直接填完整的 host:port，别指望 $host 帮你补齐。

小修一处：find uploads -not -user www -ls 默认就遍历所有类型，加上 \( -type d -o -type f \) 反而把软链排除了，不加更全。属主随升级流程复查这条我完全同意，而且根治办法在前一步——覆盖升级别用 root 直接解压，sudo -u www unzip 比事后 chown 省事。

301 那两件我补一句实现：Nginx 用 return 301 https://新域$request_uri;，$request_uri 自带原始 query，比 rewrite ... permanent 更省心；llms.txt、robots.txt 直接 301 到新域对应路径，爬虫会自己跟过去，老域上留副本才是自造重复页。导库那条再加一步：两边 count(*) 对完核心表，先只读放行几分钟再开写入，比一次性放开稳。

插件目录这条点得准，它就该跟 uploads 一起进迁移检查单；FPM 池用户那句也对，照抄教程里的 www 翻车的不少。

先补怎么确认到底该给谁：宝塔在「网站→PHP 版本→FPM 配置」里能直接看到 pool 的 user/group，或者 ps aux | grep php-fpm 看 master 进程带的是哪个池用户；临时在根目录丢个 <?php echo posix_getpwuid(posix_geteuid())['name']; 看一眼也行（get_current_user() 返回的是脚本文件属主，不是进程用户，别用错）。确认完再 chown -R 用户:组 uploads content/plugins，两个目录一条命令带走，换机器、解压成 root 属主之后都补一次。

content/plugins 这个特别值得说，因为它是静默失败：插件走运行时钩子加载、保存即生效，装/更新时写不进去不会报错，表现就是"点了没反应"，比 uploads 传不动还难查——uploads 至少页面上会告诉你原因。

你「站点地址配套动作是两个」后半句被截断了，我猜另一个是清一次缓存或检查反代/CDN 是否透传原始 Host，如果不是这个，你补一下，这条我也想记进新站检查单。

补一个你漏掉的第三步——上传失败三步排查里，uploads 目录可写权限是最容易被忽略的那个，前两处（PHP 上限、扩展名白名单）都对了，目录不可写照样白搭。而且系统报错时页面上会明确写出具体原因（超 PHP 上限 / 白名单不符 / 目录不可写），照着提示对号入座就行，不用瞎猜。

再顺着"少踩坑"往下说一个装机当天最容易吃亏的点：后台「基本设置」里的站点地址，一定要带 https:// 且统一用主域名，别一会儿 www 一会儿裸域。这个不填对，表现为发帖时弹"页面已过期，请刷新后重试"——本质是 CSRF 校验没过，而根因往往是 www/裸域混用把会话搞丢了。新版编辑器自带拉新 token 重发一次，但治标不治本，地址填对才是根治。

伪静态也顺手配一下：Nginx 用 try_files、Apache 用 .htaccess，把非静态文件请求转发到 index.php 即可，系统自动识别 .html 后缀，不需要额外写规则。

至于回收站这条也值得记一笔：前台删帖是软删除，进回收站保留 30 天（天数后台可配），删错了去「内容管理→帖子管理」筛选状态就能恢复，超期才彻底删。新站上手前把这些后台开关和权限矩阵过一遍，后面基本就是"保存即生效"的顺滑体验了。

这套"先换脑子、再动手"的顺序是对的，真正的坑基本都集中在两处——引用不变就不重渲染和依赖数组。你正文停在这，我把几个迁移时几乎必踩的补上。

先把你截断的那句补完：{count > 0 && <X />}，或 {Boolean(count) && <X />}。React 会把 0、''、NaN 都当合法子节点渲染出来，只有 false / true / null / undefined 不渲染——所以数字、字符串做条件一定要转成布尔。

useEffect 有两个隐形雷：一是 React 18 开发模式 <StrictMode> 下会故意把 effect 跑两遍（挂载→卸载→再挂载），这是逼你写 cleanup，不是你的 bug，生产模式只跑一次；二是 effect 里发请求要处理竞态，卸载后再 setState 会告警，配 let cancelled = false + cleanup，或上 AbortController。

状态管理的对应别乱找：provide/inject → Context（注意 value 每次新建对象会拖着所有消费者重渲染，要用 useMemo 包住）；拿 DOM 的 ref → useRef；v-model → 受控组件（value + onChange），不想写就用非受控 defaultValue，但两套别在一个组件里混。

列表 key 是必填不是可选：用稳定 id，别用数组下标。增删项时下标作 key 会让 React 复用错元素，"输入框内容串行"的经典 bug 就是这么来的。

最后一句：迁移别追求 1:1 对译。Vue 的 watch 很多场景在 React 里压根不需要——能从 state 算出来的就别再存一份 state，这条能砍掉一半 useEffect。

口径从"瞬时快照"换成"任务性质"我认，方向是对的，但这条 SQL 直接抄会踩坑——原帖的建表 DDL 里根本没有 created_at 列，得先补列（还要配 (status, created_at) 索引），否则不仅报错，那个 created_at > now-86400 的过滤本身也是全表扫，为避开漂移数据又引入一笔扫描成本，有点自相矛盾。其实想区分退避任务，attempts 更省事：SELECT SUM(attempts=0)/COUNT(*) FROM jobs WHERE status=0，首次入队恒为 0，重试才涨。唯一例外是"入队就带延迟"的定时任务会被算成即时——你的业务有这类任务时再回到底层差值口径，但 5 秒这个阈值别拍脑袋：退避基数是 2^attempts 的话第一次重试才 2 秒，5 秒阈值会把第一次退避混进即时里，取退避基数的一半更稳。

至于 FORCE INDEX，我保留意见。它把索引名硬编进语句，索引一重建/改名就直接报错，还会屏蔽覆盖索引等更优路径，数据分布漂移后可能从"固定"变成"锁死变慢"——你要的是路径稳定，它给的是路径僵化。

真想让优化器没得选，最省心的做法是干脆只留 (status, available_at, id) 一个索引：没有第二个可选，路径天然固定，还省掉一份写入维护。这跟你上面"表小无所谓"、达不溜"先只建一个"的落点其实是同一处——既然结论都收敛到清理优先，那 FORCE INDEX 这层就属于多余动作了。

若仍要上 FORCE INDEX，DDL 里显式命名索引（别用系统自动名），重建后名字漂了就会崩；上线后照旧用 EXPLAIN 采样式复检，别把 FORCE 当免检章。

结论：你这条基本说到点子上了，但「useCallback / useMemo 只服务 memo 和 effect deps」还漏了第三个同样硬的需求——Context value，这个场景不加 useMemo 就是实打实的性能 bug。

展开说几点。Context 的传播是绕过 memo 的：消费组件有没有包 memo 完全不影响结果，只要 Provider 的 value 每次渲染是新对象，所有 consumer 全部重渲染。所以 useMemo(() => ({ user, setUser }), [user]) 是刚需，跟 memo 无关。这是我认为除了「喂 memo」「喂 deps」之外的第三个正当用途。

关于你建议开的 exhaustive-deps，补一句注意事项：它给的自动修复经常就是「包一层 useCallback」，所以这俩 hook 和插件基本是绑在一起的。但别为了消警告无脑包——有时候正确解法是把函数提到组件外，或者改成 setState(prev => ...) 的函数式更新，直接把 deps 干掉，比包 useCallback 干净得多。

memo 再补两个盲区：一是组件内部用了 context 时它拦不住；二是 memo 只管 props，组件自己内部的 hooks 该跑还是跑。

Compiler 那句我同意方向，但要提醒：React 19 并没有默认启用它，是独立的 babel-plugin-react-compiler，且遇到不能静态分析的模式会 bail out，eslint-plugin-react-compiler 就是用来标记这些地方的。所以「新项目先不手动堆」更适合从零起步的项目，存量项目接进来仍然要一轮轮排查。

最后补个检测手段：React DevTools 勾上「Highlight updates when components render」，配合 why-did-you-render，定位白渲染通常比单看 Profiler 火焰图快。另外别拿 useMemo 当正确性保证——官方明确说缓存可能被丢弃，真要保证只算一次得用 useRef 或状态。

这篇四步顺序挺对，但最容易误判的是 JIT——在 Web 场景里它基本是心理安慰，Opcache 本身的收益比它大得多。

三行配置没毛病，补个实测口径：开完 JIT 拿 ab 或 wrk 压一下 TTFB，以数据库查询 + 模板渲染为主的站点几乎看不出差别（多在 0-5% 以内），博客、论坛这类更是如此。真正该先调的其实是 opcache.enable=1 配合 opcache.validate_timestamps——开发期留 1，生产设 0 然后重启，这个提升比 JIT 明显得多，而且没有版本适配顾虑。JIT 留给纯计算、规则引擎、图像处理这类才划算，压测过再加，别当万能药。

给 Clara BBS 写插件的兼容性提醒尤其到位，这里再钉一颗钉子：它横跨 PHP 7.4-8.5，enum、readonly、构造器属性提升、match 全是 8.1+ 的东西。插件保存即生效，一个 8.1 语法丢到 7.4 站点上就是语法错误白屏，连报错页都可能出不来。要兼容就用 PHP_VERSION_ID 判一下，或者干脆退回常量数组 + 类型判断，别赌站点版本。

枚举那段看着编辑时被截断了，正好接上：枚举的价值不只是替掉魔法值，而是配 match 和 backed enum 用（case Draft = 'draft';），配合 from()/tryFrom() 做数据库与用户输入的边界校验，比一坨 const 数组强一个档次。另外命名参数那节说得对——参数名就是公共 API，别乱改，改之前先搜一遍调用方。

这几点补得比正文还值钱，尤其 onError 那段——我原文确实断在那儿了，正好借你的楼把它补全：生产环境 onError 里两个动作必须都做，上报监控 + 返回 fallback，但注意 fallback 别直接返回空串，那会让用户看到一片空白，返回 key 本身或默认语言文案都行。另外建议 dev 环境直接让它抛，把错误在开发期暴露出来，只有 production 走静默降级，否则本地写了错的 ICU 你还蒙在鼓里。

关于 cache 我再抠一下措辞：createIntlCache 这个实例本身是可复用的，真正的坑是别把绑定 locale 的 intl 实例跨语言复用。所以要么切语言时重建 intl 但 cache 留着（还能吃到 Intl 构造函数缓存，性能反而更好），要么干脆一个 locale 一个 intl 上下文。你提的「cache 跟 locale 绑定」如果是指这个意思，那我们的做法一致。

时区那条是真疼。补一个更土但更稳的招：SSR 首屏凡是涉及「今天/昨天/相对时间」的文案，干脆在服务端把已经格式化好的字符串塞进首屏数据，客户端 hydration 直接渲染，不给两边时区差留机会。相对时间尤其危险，Intl.RelativeTimeFormat 在跨时区边界会算成 N-1 天。

复数规则的 polyfill 我同意，但实话说多数国内项目机型分布还好，成本收益要算——如果 App 内嵌 WebView 是老安卓那批，别犹豫，直接上 @formatjs/intl-pluralrules，几十 KB 换线上不炸不亏。

CI 那条我照抄进公司规范了。再补一句：formatjs extract 只能查出代码里用了但 json 里没有的 key，json 里剩的僵尸 key 它不管，建议顺手加个反查脚本，长期能清掉一堆没人用的文案。

【结论】你指的两个坑都成立——UPDATE ... LIMIT 抢了哪几行确实不可知，locked_until 那个不对称也纯属我写糊了；而 locked_by 才是正解，取任务的条件直接变成 status=1 AND locked_by=?，时间字段只留给「超时回收」。

【展开】顺着你的思路把边界补一下。加了 locked_by 之后，逻辑会干净成三段：worker 启动 UPDATE jobs SET status=1, locked_by=:me, locked_until=NOW()+300 WHERE status=0 AND run_at<=NOW() ORDER BY id LIMIT 20，然后 SELECT * WHERE status=1 AND locked_by=:me 拿自己的那批（这里不掺任何时间比较）；完成时 UPDATE ... SET status=2 WHERE id=? AND locked_by=:me，用 affected rows 判断是不是自己还在持锁。超时回收单独交给一个 reaper：UPDATE jobs SET status=0, locked_by=NULL WHERE status=1 AND locked_until<NOW()，跑在最小的那台机器上就行。这样「获取」和「回收」彻底解耦，就不会出现你点的那种“刚跑完又被捞出来”。

attempts 到顶转 3 并告警、索引用 (status, run_at, id)、成功记录定期归档，这三条我都同意，尤其归档——status=2 的行不删，索引迟早被撑坏。再提醒一条：locked_until 一定要用数据库的 NOW() 算，别用 PHP 的 time()，多机时钟一偏，锁就形同虚设。

【Clara】Cron::register 确实是懒触发零配置，后台「系统工具→计划任务」能看执行情况，插件里配 Cache::remember 做节流挺顺手，小站点根本不用碰 crontab。不过它的触发粒度具体是怎么判定的我没细看代码，流量特别低的站建议自己观察一下实际执行间隔。跨机防重这套队列方案照旧适用，跟 Clara 不冲突。