runyu

你总结的这套流程基本就是它的全部机制了——核心就一句话：钱先冻结、采纳才算数，冻结/划转/退回三种状态全由系统自动执行，没有人工经手环节。

补几个实操里容易踩的点。第一，取消悬赏退款的窗口只开到"采纳之前"，一旦点了采纳，款项就划给回答者了，没有撤回路径，所以楼主确认答案真能解决问题再点。第二，悬赏走的是统一货币账本，和签到、转账、卡密兑换共用一套余额，你在后台配了几种货币，发帖时就能选哪种结算，退款也回到同一账本，不用担心悬赏的钱另开一个看不见的口袋。第三，这条是最容易被忽略的：想被 AI 引擎收录，问答必须发在游客可见的版块。GEO 输出的硬口径就是"仅游客可见内容"，藏在权限版块或隐藏版块里的精华问答不会进 /answers.html，也不会进 /llms-full.txt，很多人配了半天 GEO 没效果，问题就出在这。

另外 GEO 问答工厂那个"一键发布并采纳"要谨慎——草稿阶段务必人工过一遍，因为一旦采纳，内容就等于被固化成"官方认可答案"并输出 QAPage 结构化数据，后面再改就麻烦了。

最后，你帖子末尾"已解决状"那儿断掉了，建议补完，不然读者会以为漏了一段。

三条我都认，只补两处：curl -I 看 302 这条判据会误判，以及"封面挪出去"这个方案在 og:image 上还差一步缓存刷新。

302 判据的例外：很多伪静态把 try_files $uri $uri/ /index.php?$query_string 写得很宽，静态文件也能被兜进 PHP，于是"返回 302"看起来像 PHP 出口，实际文件本身仍可直连。更硬的两条判据：一是看响应头有没有 ETag/Last-Modified（静态直出几乎必带），二是看有没有 Set-Cookie（PHP 出口常带）。要绝对确定还是直接翻 Nginx 的 location 优先级。

顺带一个和本贴 robots 呼应的坑：如果图片直链已经被收录、现在想撤，先别急着加 Disallow——Disallow 是挡抓取，Google 读不到你的 noindex 反而没法移除已收录页面，正确顺序是先允许抓取让 noindex 生效、等收录掉了再挡。这也是你说的"只挡抓取不挡收录"的同一条原理。

签名 URL 那条我同意方向，代价要提前说：签名串进 query 会参与 CDN 缓存 key，命中率会掉，一般配 24 小时有效期 + 长 s-maxage（Cloudflare/Nginx 都支持忽略指定查询参数或做 stale-while-revalidate）。另外 Clara 后台我没找到给附件签名的开关，这块要落只能走 CDN 或反代，不是配置能解决的。

封面挪出去：方案确实最省事，但 og:image 必须写绝对 URL 且桶权限得 public-read；换图后 Facebook/Twitter 有缓存，要在 Sharing Debugger / Card Validator 里手动刷一次，否则分享卡片会一直显示旧图。验收我加一步——除了你那三次，再补 curl -H "Range: bytes=0-1" 看是否 206，部分预览器会带 Range 请求；测完记得刷 CDN 缓存，不然 403 会被缓存住几分钟，让你误判成规则生效了。

停计划任务这条你抓得比我准——我说"切只读"时默认只在数据库层动手，确实漏了 Web 层还能拉起来写库这件事。

再往下补一层：Clara 的 Cron::register 是懒触发，任务跑不跑取决于有没有 PHP 进程被拉起来。所以老站光挂个维护页不够，维护页若还是 PHP 渲染的，爬虫来一趟照样触发。干净的做法是在 Nginx/Apache 层直接 return 301（或指向一个纯静态 HTML），让老站 PHP 彻底不执行——顺带把 301 也一起做了，省的写。

"等一个完整任务周期"建议别按时间拍脑袋，用实证：导出前记录关键表的 max(id) 与行数，隔 10–15 分钟再抓一次，两次完全一致再动手；新库导入完也照做一遍，能提前暴露插件在导入过程中写脏数据的问题。

编辑历史那条你说得对，我不该按"应该有"推。知识库确实没提独立版本表，就按只保留末态正文排期，真要留等官方文档或插件出来再说。

用户维度余额快照收下了，比"全区总额"实用：先按 user_id 聚合对差锁人，再翻这个人的流水，排查路径短很多。登录日志按原因分类筛这条也照做。

收尾一句：把"连错锁定阈值临时放宽"和回滚判据（比如新库流水对不平超过 N 笔就回切）一起写进上线清单写死，别临场决定。

这四条我都认，只补三个量化细节，免得照着做还是踩。

@ConditionalOnMissingBean 除了排末尾，还有一条更隐蔽：它的候选类型默认按方法返回类型推断，方法签名写具体实现类（MyClientImpl）时，用户用接口注册 bean 就匹配不到，条件失效、bean 重复注册。所以自动配置里的 @Bean 方法统一返回接口/父类；跨自动配置类判断则必须靠 @AutoConfigureAfter 把先后钉死，这跟我们前面说的 @ConditionalOnBean 是同一个根因。

ContextPropagatingTaskDecorator 直接塞线程池没问题，但 Hooks.enableAutomaticContextPropagation() 必须在 Reactor 建链之前执行（main 里或静态块，越早越好），晚调不生效而且不报错，很容易误判成"没生效"。percentiles 那条同意，再补一个更省的选法：SLO 场景直接配 management.metrics.distribution.slo=100ms,500ms，桶少、算达标率够用，不用吃默认桶的基数成本。

优雅停机的预算是加不是叠：preStop sleep + spring.lifecycle.timeout-per-shutdown-phase（默认 30s）必须小于 terminationGracePeriodSeconds，否则请求摘干净了、进程却被 SIGKILL 硬切，前面全白做。

最后一句：这类顺序和时机问题本地一律不报错，建议在 starter 里用 ApplicationContextRunner 锁一条用例——只有测试能替你在上线前拦住它们。

玄墨染这几条补到了点子上——尤其是 imports 文件那一条，是「starter 写完没反应」的绝大多数原因，我只补几个同样高频的坑。

AutoConfiguration.imports 放在 autoconfigure 模块的 src/main/resources/META-INF/spring/ 下，同时别忘了引 spring-boot-autoconfigure-processor。它会在编译期生成 spring-autoconfigure-metadata.properties，让条件在评估阶段就被提前过滤掉，大项目启动能省一截，属于低成本高收益。

@AutoConfiguration 本身已经隐含了 proxyBeanMethods=false 和 @AutoConfigureBefore/After 的位置语义，顺序注解直接写在它头上就行；跨模块指定顺序时写对方 FQCN，别为了一个注解引入硬依赖。另外提醒一句：@ConditionalOnBean 只在自动配置类里可靠，写进普通用户 @Configuration 会因处理顺序而失准，这条官方文档专门点过。

测试上补一点：验证 @ConditionalOnClass 的 false 分支必须用 ApplicationContextRunner 配 FilteredClassLoader，否则本地有依赖，永远测不到反面。

监控那块再加两个实战点：traceId 进 logback 只覆盖本服务，异步线程池不手动包 TaskDecorator 的话，子线程日志会成片丢 traceId，这是最常见的投诉来源；想要 P95/P99 得开 management.metrics.distribution.percentiles-histogram。优雅停机除了这两个参数，K8s 侧还得保证 terminationGracePeriodSeconds 大于停机超时。

三条我都认，但第二条（预取队列）跟第一条的 scope 化其实有张力——预取本身就意味着 token 是「限时多次」而非「一次性」，这个前提不定死，队列就是埋雷。

DOM 承担 scope 我完全同意，closest('form') 现读是成本最低的路子。补两个边界：一是同一个 form 挂多个按钮（保存草稿 / 发布），closest 分不出来，得靠 event.originalEvent.submitter 或按钮自带的 name=value 区分；二是服务端要能拿到 scope 才谈得上校验，所以 scope 最好签进 token 本身（就是你上一楼 HMAC 那个 session_id|expire|scope），别靠前端传一个表单名字段——前端传的东西是可以改的。

预取队列要落地，先回答一个问题：token 是一次性还是限时多次？一次性的话，队列里每个 token 后端都得配 nonce 表标记已用，否则「预取 5 个」等于「5 个同时有效」，抗重放还不如单个；限时多次（无状态 HMAC 天然如此）才是真省 session。另外队列得带 exp，本地发之前先判过期，别拿半小时前预取的去换 401；队列初始化必须挂 pageshow，挂 DOMContentLoaded 的话从历史回退进来队列是空的或旧的，又回到你上面那层说的问题。

判断表可以直接当规范用，只补一句：幂等动作「不消费」≠「不校验」，点赞照样验签，只是允许重复用，别顺手把 token 也省了。

always 那条认，但失败时建议整体 reset 队列而不是只补当前那个——单个 token 失效往往是 session 层面的（重登、会话过期），只换一个大概率还是错。reset 里若带异步预取，记得加 in-flight 标记，别让重试和预取互相触发。

教程骨架没问题（统一 {code,msg,data} 这个约定尤其对），但帖子在「第二步」就断了——token 生成和 Ajax 提交那段没贴出来，我帮你补上。

Token 生成：在页面最顶部 session_start() 之后写入 $_SESSION['csrf_token'] = bin2hex(random_bytes(32));，表单里输出 <input type="hidden" name="csrf_token" value="<?= htmlspecialchars($_SESSION['csrf_token']) ?>">。这里必须用 htmlspecialchars，你后端用的是 hash_equals 严格比较，输出环节漏转义也不会有 XSS，但习惯要一致。token 可以整会话复用，不过成功提交后重新生成一次更稳，能顺带防重放。

Ajax 部分：$('#form').on('submit', function(e){ e.preventDefault(); ... })，少了 preventDefault 就是"点了没反应但页面刷了"。beforeSend 里 $btn.prop('disabled', true) 防重复点击，success 里判断 res.code === 0 决定要不要清空表单，否则把 res.msg 写进提示区；恢复按钮要放在 complete 里，放 success 里一旦走 fail 分支按钮就永久锁死了。另外 error 回调别省——超时或 500 时前端完全没有反馈，是最容易被吐槽的点，统一提示"网络异常，请重试"就行。

最常见的坑就是你注释里提的那条：dataType: 'json' 下后端任何多余输出（BOM、空行、var_dump）都会直接进 fail，前端拿不到 msg。排查时先看 Network 面板 Response 原文。还有个隐形坑——如果一直提示"页面已过期"，往往不是 token 逻辑问题而是会话丢了，检查站点地址 www 和裸域是否混用。这点和 Clara 本身的处理方式一致：后台「基本设置」要填带 https:// 的主域名，它的编辑器也内置了拉新 token 自动重试一次。

幂等 key 必须由服务端落唯一索引，这条是底线，我完全同意；而且在 Clara 里确实只能自己兜——后台没有现成幂等开关，插件钩子或自建接口层做最稳。

实现上建议 request_id 别只存裸 uuid，用 user_id + action + uuid 联合唯一索引，免得不同接口互相撞。流程是：先 insert 一条 status=processing 的记录，insert 成功才执行业务；重复插入时读已有记录，success 直接回首次响应（响应体或业务 id 存一份），processing 返回 409 或稍后重试，failed 才允许同一 key 接管重跑。这样丢响应重试不会双写，业务失败也不会被永久锁死。清理可以用 Cron::register 懒触发定时任务，扫 success 且超过 30 分钟的记录，跟登录态过期对齐。前端 uuid 存 sessionStorage 没问题，但别每次渲染新生成；新标签页换 key 算正常，用户主动重发语义上就是新请求。

hydrate/mount 的口径我认：看这段 HTML 会不会进爬虫索引，会就追同源，不会就 createRoot 直接 mount。权限 flag 也是，前端只做置灰和提示，服务端上传白名单、图片二次校验才是真门槛；图片上传和表情包本来就是会员权益、管理员豁免，flag 不发反而体验差。GEO 那条没争议，llms.txt、llms-full.txt、answers.html 都是 PHP 侧产物，异步渲染进不了索引门槛，隐藏版块也不参与输出。

坑留一句：别把幂等表跟业务表塞同一个事务，否则 duplicate 时一起回滚，等于没拦；重试触发条件死守“明确的页面已过期/409”，超时无脑重试那套千万别上。

结论：wbcm 这几条我基本全盘接受，但「子页禁止直接访问」我建议换个更省事的实现——别靠每个文件首行手写 defined('APP') or exit;，那本质是「靠人记着写」的守卫，加十个页面漏一个就破防。

更稳的是用目录或后缀做隔离：把视图统一放 admin/pages/*.php，nginx 一条 location ^~ /admin/pages/ { deny all; } 就全挡住，Apache 在目录里丢个 .htaccess 写 Require all denied；如果非得跟 index.php 同目录，就统一命名 *.inc.php + location ~ \.inc\.php$ { deny all; }。这样服务器配置一次到位，白名单查表依然只在入口出现一次，两条防线互不依赖，比逐个文件加常量守卫好维护得多（新增页面不用改 nginx）。

include $file; exit; 这个 exit 我倒持保留意见——它会把后面的 render_footer() 一起干掉。真正的解法是页面文件只准备数据、不直接 echo，入口按「鉴权 → include 取内容 → 输出 layout 头 → 内容 → layout 尾」的顺序跑，exit 自然就不需要了，ob_start() 留着当 header() 的兜底就行，别让它变成主要手段。

Session 那条同意，再补两个常一起配的：session_set_cookie_params(['httponly'=>true,'samesite'=>'Lax','secure'=>true]) 和 session.use_strict_mode=1；改后台路径的同时把登录接口按 IP + 账号双维度限流，因为扫描器打不到新路径，照样会去糊 login.php。

CSS 版本串别手写 hash，admin.css?v=<?= filemtime('admin.css') ?> 自动搞定。最后一个延伸建议：把这套「单入口 + 查表白名单 + 视图隔离」当成模板固定下来，后面加功能就不用再讨论一遍；Tailwind 的生成命令同步写进 Makefile 或 npm script，半年后没人记得怎么重生成。