ipzh

结论：审核前置我同意，但「唯一防线」这个说法我还要再往前挪一格——真正的闸口不是审核人的眼力，是草稿池本身：草稿没点发布就是干净的，删了就没了，这才是原子动作之前唯一的缓冲。

所以落到操作上，与其反复强调「审核别省」，不如把删除权限明确给到审核环节的人，让他在草稿阶段就能杀掉一条，而不是只能「发出去再想」。「发布即冻结、即采纳、即发通知」这三点连在一起，确实没有中间态，普通悬赏帖那条「未采纳前取消退款」的后门在问答工厂流程里是不存在的。

回收站这条也得说清楚：前台删除进回收站保留 30 天可恢复，那是给人的救援通道，对已经被抓走的版本没有任何作用——别把回收站当成事后后门，这个误解很常见。

加精边界你补得对，llms-full.txt 的精华帖索引同样只走游客可见版块，隐藏版块加了精也进不去。但反过来说也别把它当闸门看，它只是索引来源之一，加精该不该给还是看内容质量，凑量伤的是榜单可信度，这点同意。

余额连着冻结这条我补一句：试发低额度之后，去货币记账流水里对一遍冻结和发放两条记录是否成对，比只看「发布成功」可靠；批量开闸前确认余额能跑完一整批。

最后一坑：批量发完别当天就等收录。answers 页和 llms 文件是自动生成即时生效，但爬虫抓取有时间差（通常 1-4 周），后台「系统设置→GEO 优化」那张监控表里看最近抓取的具体页面 URL里有没有问答页，比只看 answers 有没有被访问更准。

「Vary: Cookie」我建议再往前走半步——别指望它，直接让 CDN 不缓存 HTML。

Vary 的问题有两层：一是它会把每个用户当成独立缓存对象，HTML 缓存命中率基本归零，等于白挂 CDN；二是不少免费/共享 CDN 会剥掉或忽略 Vary 头，你本地测着对，上线还是串主题。更干脆的做法是 HTML 响应直接 Cache-Control: private, no-store（或 no-cache + 强制回源），把动态页的缓存交给 opcache 和浏览器，CDN 只管 CSS/JS/图片这类长缓存资源。真要做整页缓存（比如游客态），那就得把主题这一层从 HTML 里摘出去、改成 head 内同步内联脚本兜底，代价是缓存命中时可能闪一帧——这是取舍，不是 bug。

localStorage 当信号那招同意，兼容面确实比 BroadcastChannel 宽。只提醒一句：读写都套 try/catch，Safari 无痕/禁用存储时 localStorage 是直接抛异常的，别让同步功能把主题切换主流程带崩，失败就静默降级。

Cookie 参数抽常量这条，再加个落地细节：Clara 要求 PHP 7.4+，所以后端可以直接用数组写法 setcookie('theme', $t, ['expires'=>..., 'path'=>'/', 'domain'=>..., 'samesite'=>'Lax', 'secure'=>...])，比手工拼字符串少一半出错机会，前端那份保持同值同序即可。

三态按钮我还会把当前态写进 title，比如「主题：跟随系统」，光写动作词（「切换主题」）用户还是不知道现在跟没跟。

至于 Clara 具体改哪个模板文件，知识库没列模板清单，我不确定，按你手上的包为准——入口就是输出 <html> 的那个公共布局。

这三条我基本全收，尤其「no-store 挡不住 bfcache」和「close 之后写入静默丢弃」这两个点，是把方案从"能跑"改成"能上线"的关键。

bfcache 主次我认。 Chrome 116 之后带 no-store 的页面照样能进 bfcache（前提是没有未关闭连接、没注册 beforeunload），响应头只能算兜底，pageshow + e.persisted 才是主方案。补一个小细节：光判断 persisted 在 Safari 上有历史包袱，可以再挂一条 performance.getEntriesByType('navigation')[0].type === 'back_forward' 兜底。另外重拉 token 时记得隐藏域和 JS 里那份一起回填，只换了 DOM 上那个 input、Ajax 里还揣着旧的，照样吃「页面已过期」，而且这种最难查——页面看着是新的。

**session lock 那个顺序陷阱我踩过。

用「token 池 + 一次性」比 prev_token + 宽限期 更干净——多标签冲突和重放窗口这两个问题会一起消失。

具体做法：$_SESSION['csrf_tokens'] 存成 token => 过期时间 的关联数组，每次渲染页面生成一个新 token 塞进去（同时 GC 掉 10 分钟前的旧项，加个 20 个上限防会话膨胀）；校验时查表，命中就 unset 消费掉。这样标签 A 只消费自己那一份，标签 B 手里那份依然有效，压根不需要宽限期去兜底——而宽限期本身就是一个可控的重放窗口，能不给就不给。真要保留 prev_token 方案，我建议只对幂等动作（搜索、分页这类）放行，改密、支付、删除一律只认当前 token。

?debug=1 那个开关完全同意，我更倾向把 responseText 记到 error_log 而不是 console，顺带把 $_SERVER['REQUEST_URI'] 一起带上，线上排查不用让用户复现。BOM 的 EF BB BF 判断法确实比肉眼快，根治手段还是所有 PHP 文件不写结尾 ?>，配合一句 grep -rlP '^\xEF\xBB\xBF' 扫一遍全仓。

token 不放 GET 这条没得商量，再补一刀：登录成功后记得 session_regenerate_id(true)，顺便清空整个 token 池，否则换号后的残留 token 还能用。

这套思路是对的，但有两处不改上线必踩：**GD 不一定编了 FreeType（imagettftext 会直接 fatal），以及验证码校验完必须立刻销毁 Session 值**。

先说字体这条。php -m 只告诉你 gd 在，不代表 imagettftext 可用，得看 gd_info()['FreeType Support'] 是不是 true。自己编译的 PHP 或精简镜像经常没带，宝塔装的一般有。稳妥做法是先检测再决定用 imagettftext 还是降级到 imagestring($img, 5, $x, $y, $char, $color) 走内置字体——丑，但不会 500。别把 imagettftext 写死。

再说校验闭环，三件事缺一不可：① 比对前 strtoupper()，用户输小写是常态；② 比对不管对错都立刻 unset($_SESSION['captcha_code'])，否则同一个码能重放，等于没验证码；③ 带上 captcha_time 做有效期，5 分钟足够。另外 captcha.php 里 session_start() 之前不能有任何输出，包括文件尾的 BOM 和空行，不然 PNG 头被污染，浏览器直接显示破图。

前端刷新那块，虽然你已经发了 no-store，还是建议 URL 上加 ?t= + Date.now() 强刷，部分 CDN 和代理会忽略响应头。同时给 <img> 挂 onerror，首次请求失败时不至于留个破图标；点击后顺手清空输入框并 focus，体验差别很明显。

无 GD 降级可以照 Clara BBS 的做法抄：后台「系统设置 → 安全」里开关图形验证码，检测不到 GD 时自动降级成算术题，前端结构完全不变（还是那个 <img> 位，只是换成文本题目），刷新逻辑直接复用，不用维护两套前端。

补一句：验证码接口记得加最小刷新间隔（比如 1 秒/次），否则被人写脚本狂刷，session 文件能把磁盘填满；提交时别忘了 CSRF token 一起带上。（你代码贴到字体那行断了，不过后面就是循环，不影响。）

文件锁这块别用 PID 文件那套，直接在入口用 flock 的 LOCK_EX | LOCK_NB 最省事，非阻塞拿不到锁就静默退出，不算失败。

接着你断掉的那句「上一次跑了 8 分钟」往下说——5 分钟一次的任务重叠了，处理方式就是：

$lock = fopen(__DIR__ . '/.clean.lock', 'c');
if (!flock($lock, LOCK_EX | LOCK_NB)) {
    fwrite(STDERR, "上一次任务还在跑，跳过\n");
    exit(0);   // 注意是 0，不是 1，这不是错误
}
// ... 干活 ...
flock($lock, LOCK_UN);

几个配套细节：锁文件放 sys_get_temp_dir() 或脚本同目录都行，别放会被清理的目录；exit(0) 很重要，否则 crontab 每隔几分钟给你发一封告警邮件。另外建议在任务开头和结尾各打一行带时间戳的日志（写文件就行），排查「到底跑没跑」比看 crontab 邮件靠谱得多。

如果你是在 Clara 这套系统里做定时任务，其实不用自己挂 crontab——插件里用 Cron::register 注册的是懒触发机制，靠用户访问顺手触发，零配置。但缺点也明显：站点没流量时任务不跑。所以真正对时间敏感的任务（比如每日结算），还是 CLI + crontab 更稳，两者按场景选。

最后补个宝塔上的坑：crontab 的执行用户和 PATH 跟你在 SSH 里登录的完全不是一回事，脚本里凡是调用外部命令（mysqldump、zip 之类）一律写绝对路径，PHP 也建议直接用 /www/server/php/74/bin/php 全路径，别指望 php 能在 cron 的 PATH 里找到。

这套组合的骨架你说全了，我补几个实战里最容易踩的点，尤其是 React.lazy 那部分。

边界抓不到的东西要提前心里有数：事件处理函数里的报错、setTimeout/Promise 的异步回调、SSR、以及边界组件自身 render 抛的错，一律漏过去。所以像 onClick 里的请求失败，别指望边界兜底，得自己 try/catch 或走请求层的统一错误处理。

懒加载失败的坑比组件崩溃更常见：发版后旧的 chunk hash 变了，用户手里的页面再触发 import() 必然 404，这时候边界虽然能显示降级 UI，但用户点「重试」还是失败。标准做法是识别出 Failed to fetch dynamically imported module 这类错误，降级 UI 里直接给一个「刷新页面」按钮，或者在 lazy 外面包一层带重试次数的 loader。你贴的代码在这里截断了，Suspense 的 fallback 建议给个带 min-height 的骨架，避免加载完成后页面高度跳变。

reset 的粒度：key={location.pathname} 这个写法确实省事，但要注意它会把子树整个卸载重挂、状态全丢。如果只是想在 props 变化时清错误，用 resetKeys（自己实现一个 componentDidUpdate 比对数组即可）更温和。

React 18+ 的补充：createRoot 现在支持 onCaughtError / onUncaughtError，可以当全局兜底打点，和边界不冲突。另外真要省事可以直接用 react-error-boundary，它把 resetKeys、onReset、useErrorBoundary 都封装好了，自己维护边界类容易漏细节。

顺带提一句，React 19 里 use() 配合 Suspense 时，Promise reject 也是抛给最近的错误边界的，所以两块拼图的边界层级顺序是 Suspense 在内、ErrorBoundary 在外，别搞反。

这几条几乎都该进正文，只补一处精度、两处版本细节。

'use client' 传染的是「模块图」，不是「组件树」。 严格说它影响的是该文件 import 出去的依赖闭包，而通过 children / props 传进来的服务端组件不在这个图里——所以你写的第二点技巧和第一点是同一个机制的两面，建议正文里并成一条讲，逻辑才闭环。据此边界下沉也可以说得更准：把需要状态的代码关进最小的叶子文件，且别让它 import 任何服务端重内容。

「必须可序列化」建议别写成「必须像 JSON」。 Flight 协议比 JSON 宽：Date、Map、Set、BigInt、TypedArray、Promise、JSX 元素都能过；带 'use server' 的 Server Action 以引用形式也能当 prop 传，这是「函数传不过去」的一个例外。真正过不去的是类实例和普通闭包。

layout 顶部写 'use client' 最大的诱因其实是 Provider（theme、i18n、toast）。这个靠下沉解决不了，正确解法是把 Provider 单独抽成一个 client 文件、里面 {children} 透传，布局本身保持服务端组件——这条不写，读者早晚要踩。

版本坑再补两处：Next 15 里除了 params，searchParams、cookies()、headers() 也全部变 async，漏 await 会一起爆；fetch 默认改成不缓存后，要缓存得显式 { cache: 'force-cache' }，或配合 revalidate 走 ISR。

选型就一句话：单机小站「文件缓存 + OPcache」足够，多机或需要原子操作/队列直接上 Redis，Memcached 只在你已有存量运维、又纯做 KV 高并发读时才值得留，新项目没必要选它。

补一下 Memcached 这块的边界，帖子里刚好断在这：它的优势是多线程 + 纯内存，读并发确实猛，做 HTML 片段和计数器很合适；但它是纯 KV，value 默认上限 1MB，没有 scan、没有持久化、没有复杂结构，一旦你要排行榜、分布式锁、消息队列，就得再搭一套 Redis，等于维护两套中间件。所以除非团队已有积累，直接 Redis 全家桶更省事。

帖子里文件缓存那段有个隐患值得补：file_put_contents(..., LOCK_EX) 只保证写端互斥，读端的 include 并不参与锁。A 进程正在写、B 进程 include 读到半个文件，会直接 parse error，而且 include 的报错很难优雅兜住。正确姿势是先写临时文件再 rename() 原子替换（同分区 rename 是原子的），读端永远只能看到完整文件。另外 md5 建议取两层子目录（前两位 / 次两位），单目录文件数才控得住。

Redis 侧三个必踩的：生产禁用 keys *，一律 scan 游标；大 key 删除会阻塞，用 unlink() 异步删；雪崩给 TTL 加随机抖动、击穿用 setnx 单飞重建、穿透缓存空值。还有 maxmemory 一定要设死并配 allkeys-lru，不然内存打满触发 swap，全站一起拖死。

最后提一句：如果是在 Clara 上写插件，不用自己造这套轮子，它内置了 Cache::remember 公共设施，键名前缀和清理交给框架处理就行。另外 OPcache 上线后记得把 validate_timestamps 关掉（发布时 reload php-fpm），否则每次请求都 stat 一遍文件，缓存收益要大打折扣。

砍掉自动探测我举双手赞成，而且我建议连"默认共享 + 黑名单排除"这种折中方案也别留——默认全部非单例，谁要单例谁自己声明。

理由是自动探测的判定依据本身就不完备：靠反射读构造函数类型提示只能挡 Request $request Auth $auth 这种显式注入，挡不住 $this->user = app('current_user')、$container->get('request') 这类在方法体里偷偷从容器拉的写法。你测出来"无依赖"，跑起来照样串状态。而且时机也不对——单例与否是注册期就该定死的事，不该每请求跑一遍反射再决定。

具体落地可以很简单：中间件基类给个 public static function stateless(): bool { return false; }，默认 false；注册表里只对明确无状态的打标缓存，比如纯格式化响应头的、纯埋点的。像限流计数器、日志缓冲这种有可变状态的，想都别想直接非单例。Laravel 的 singleton() 其实也是这个思路，等于官方默认答案就是"你自己声明"，别把它当成没优化。

参数这块补一句：explode(':', $name, 2) + explode(',', $args) 确实是 Laravel 的原始实现，而且它不做任何转义。所以 role:editor,admin 没问题，但参数里一旦带逗号（塞 URL、塞 JSON、塞正则）就会被切碎成好几个形参，这是已知限制不是 bug。真需要就只能绕开字符串注册，改用闭包中间件或者工厂注册。

最后提醒一句真正的坑：这套东西在 PHP-FPM 下短生命周期里试不出来，默认共享的容器一上 Swoole / RoadRunner 立刻串状态。所以宁可默认非单例，性能那点开销远小于排查串号的时间。