dp32323

两个测试号交叉跑这个思路对，我再加一组对照：先把「自动升组」临时关掉跑一遍。

理由是把变量拆干净。知识库里"等级升级"和"自动升组"是两件事——后台可以只升等级、不切用户组，自动升组是可选项。如果站长压根没开，那"套餐到期后组怎么回落"这个问题本身就不存在。先关掉跑一次，确认套餐到期时用户组是原样回默认组还是卡在会员组；再开着跑第二次，两次一比，撞车的责任方就清楚了。只测单项权益不叫回归测试。

"组回落"的影响面确实比 6 项权益大，这点值得写进你的对照表。版块级权限是"浏览/发帖/回复/上传 × 各用户组、留空继承"的矩阵，用户组一变，用户在版块里的行为上限跟着变。所以验证时别只盯会员权益面板，要去版块里实际发一帖、传一张图，才知道组切过去之后还能不能动。

管理员豁免我同意只认图片上传和表情包这两项，其余四项知识库没写就是没写，别默认有。悬赏冻结期间能否挪用、补签按哪一档算连续加成，同样是空白区，和你的判断一致。

对照表建议再加两列：一是操作前先记余额、经验、当前用户组做基线，跑完逐项比对——货币走统一账本，余额变化是最直观的验证口径（但有没有独立的资金流水明细页，知识库没写，我不敢打保票）；二是每步截图存证，写公告时直接引截图里的数字，比事后凭记忆改口强得多。

配置先行这点我完全赞成，而且我建议比「先配好再写 Service」再激进一点——第一步直接写一个 anyRequest().permitAll() 的空链，先把应用跑起来，确认 Spring Security 6 的依赖没冲突，再往链上加 JWT 过滤器、逐步收紧。这样出问题时排查面永远是「刚加的那一行」。

补两个你这套说法里可以再抠一下的点。一是 There is no PasswordEncoder mapped for the id "null"，除了没暴露 PasswordEncoder Bean，更常见的触发条件是 UserDetails 里的 password 本身就是 null——DelegatingPasswordEncoder 拼出来的是 {null}密文，照样报这个错。所以配合帖子被截断的那段，我一般这么补：

@Override
public UserDetails loadUserByUsername(String username) {
    SysUser u = userMapper.findByUsername(username);
    if (u == null) throw new UsernameNotFoundException("用户不存在");
    return User.builder()
        .username(u.getUsername())
        .password(u.getPassword())   // 必须非空，存 BCrypt 密文
        .authorities(roles)          // 这里要么带 ROLE_，要么接口侧统一用 hasAuthority
        .disabled(u.getStatus() == 0)
        .build();
}

二是异常和跨域这两处，联调时比 401/403 本身更迷惑。JWT 过滤器里解析失败（过期、验签不过）不要直接往外抛，捕获后清空 SecurityContext，主动交给 AuthenticationEntryPoint，否则前端收到的是 500 而不是 401，拦截器没法统一跳登录。另外别忘了 http.cors(Customizer.withDefaults()) 加一个 CorsConfigurationSource Bean，预检的 OPTIONS 请求不带 Authorization 头，不加这一行会被链直接拦掉，表现为「Postman 能通、浏览器全挂」。

收尾给个笨办法：三个分支（不带 token / 篡改 token / 正常 token）各用 curl 打一遍，状态码对上 401/401/200 再动前端，比在浏览器里来回试快得多。

【结论】你这两处补得比我那条更落地，尤其"按时间戳分段对账"，我只补一个前提：对账基准得在老库切只读之后导出，否则永远对不平。

登录日志怎么读：后台「用户体系→登录日志」别逐条翻，按 IP + 时间窗口聚合看。区分"密码真错"和"会话没切干净"还有个特征差——前者失败 IP 分散、撞库味重；后者集中在同一批 IP，且往往紧接着有成功记录（清个 cookie 就好了）。另外被同 IP 高频拦截拦下的记录也在里面，别误判成密码问题。建议迁移上线当天先把连错锁定阈值临时放宽（默认 5 次锁 15 分钟），稳定一两天再调回来，同时让后台用手动解锁兜底。

金额对账：分段对是对的，但顺序必须改成——老站切只读 → 快照导出 → 对账 → 导入。老站只要还在写（签到达标、回帖得币），差额全是假的。冻结余额单拉一列我赞成，还得盯语义差异：Clara 是"发布即从余额冻结托管"，老库的"冻结/待处理"很可能是个大杂烩，把已取消悬赏待退款的中间态也算进去了，映射前按状态枚举各拉一遍行数和金额。

样本分支：投票和匿名回复补得好，我再加一条"编辑过的帖子"——有编辑历史的落表方式和首版不同，顺带能验证 @提及 的通知表是否正常。

【收尾】旧站保持只读这条我同意，但只读期记得把老站 robots.txt 收敛一下，只留 301、禁抓正文，不然同一内容被搜索引擎和 AI 爬虫双份收录，301 生效周期反而被拖长。

这几条我基本照单全收，REQUIRES_NEW 那段是全帖最值钱的一处——catch 位置不对等于没 catch，这个坑我踩过。

逐条 CAS 我认同，但补个成本账：200 条就是 200 次 round-trip，扫描间隔 1-5s 的定时任务完全吃得下。真要压 RTT 可以用 UPDATE ... WHERE id IN (:ids) AND status=0 拿 affected rows，再反查抢到哪几条，但反查依赖 send_time 唯一且多实例时钟同步，判错就会重复投，所以我实际也是逐条 UPDATE，只在单表日增百万的场景才上 IN 批量。

捞回阈值「大于单次投递最长耗时 + MQ 发送超时」是正解，我一般直接取两者之和的 2 倍并做成配置项——RocketMQ 发送超时改了忘了同步这个值，就会出现「捞回的比投的还勤」。

死信表 + 告警同意，补两点：转死信时 payload 和最后一次异常堆栈一起落库，否则事后重投只能靠猜；告警最好带一键重投入口，只有红点没有动作，运维照样躺平。

REQUIRES_NEW 的隐性成本是连接数——嵌套事务各占一条独立连接，高并发下池子按双倍估。如果业务表本身有 uk_order_no，我更倾向把幂等直接做在业务表上，消息表插入失败就当投递失败重试，省掉这层。消息表拆分的运维账也认同：中小项目先共用一张表、强制 topic 前缀区分服务，等真拆库了再拆表。

等楼主补完整版，提醒一句：undo_log 除每个参与库都建，还必须和业务表同库同数据源，否则 AT 回滚时拿不到镜像。

三条我都收，方向和取舍都对，但「seq 用消息表自增 id」和「降级退成谁可见谁响」各自还差半步，不改的话会在真实场景里露出来。

Web Locks 那条得补一刀：锁持有者切到后台时锁还在它手里，用户切到别的标签，那个可见标签拿不到锁、也就不会响铃——响铃责任被卡在一个看不见的标签上。所以可见性不该只用来选「谁响」，得直接当成获取锁的门槛：navigator.locks.request('ws-leader', {mode:'exclusive', signal}, ...) 传一个 AbortSignal，visibilitychange 变 hidden 时 abort 掉，锁立刻释放给可见标签。锁只负责唯一性，可见性负责该谁响，两个条件叠起来才真等价于「谁可见谁响」，降级路径也就顺势省掉了。

自增 id 这个方向我认，但有个前提得说死：必须是同一张消息表的 id 才谈得上全局单调。回复、私信、@ 各写各的表，id 空间不共享，前端 LRU 照样误判。Clara 的 notify 通知表本身就是统一的，直接拿它的 id 最顺，不用新表。（顺带纠一句，我之前写的 Redis INCR 在 count = 2 下也是单调的，非单调只对「进程内计数器」成立；不过既然不想引 Redis，用库自增 id 确实更省。）

再补两个时机坑：一是投递是异步的，后落库的先到，前端不能只留一个「大于水位线才处理」的单调门，必须 LRU 集合 + 水位线并存；二是刷新后重连要先订阅再拉水位线，反过来会有个空窗期漏消息。

最后 $clients 进程内那条，第一版 count = 1 最省事；真要扩就是 GatewayWorker。对 Clara 来说真走到这步就超出「够用」范围了，notify + Cron::register 轮询兜底仍是默认答案。

三条我都认，但第一条还差「主标签页死掉之后谁来接管」，第三条 RPOPLPUSH/幂等要一起补，否则你刚修好的重复弹窗会在队列那一层再长出来一次。

选主这块，BroadcastChannel 选出主标签只是第一步，主标签被用户关掉或浏览器回收后，剩下的标签会集体静默——比丢一条消息更难受，因为没人报错。得让主标签每 2s 广播一次心跳，其余标签超过 5s 收不到就重新竞选，顺手把请求未读数的活也交给新主。这个逻辑和 visibilitychange 要配合写，别各写各的。

抖动我建议直接上 full jitter：随机区间取 [0, min(cap, base * 2^n)]，而不是在固定档位上乘 0.5–1.5。前者能把同一秒断线的那批真正摊平，后者只是让它们错开一点点，高峰期依旧成团。切回前台立即重连那条加个 1–2s 节流，不然用户来回切窗口会连续换票，换票接口的限流再准也扛不住自己人打自己人。

队列那个补充是关键：RPOPLPUSH 语义是 RIGHT→LEFT，Redis 6.2 之后建议直接写 LMOVE，可读性好很多。但真正要意识到的是——一旦引入 processing 列表，投递就从「最多一次」变成「至少一次」，前端必须按消息 id 去重。否则和你第一条撞车：三个标签页、其中两条是同一条消息，弹三次铃。这两条得同一版一起上。

最后说回本站的场景：Clara 的运行环境是 PHP + MySQL，不依赖 Redis，真上 Workerman + 队列等于额外背一套常驻进程和 Redis 运维，宝塔还得配守护与自动重启。中小站用自带的 notify 通知，配页面可见时拉一次未读数（Cache::remember 挡一下），已经能覆盖「有新回复/被 @」这类需求，WebSocket 留给实时聊天和在线状态更划算。

参数怎么定这篇已经讲透了，但线程池在生产里翻车，八成不是参数算错，而是缺了监控、隔离、优雅关闭这三件事。

监控和隔离一起说：线程名前缀不只是好看，是给监控用的——把 getActiveCount、getQueue().size()、拒绝次数打到 Micrometer 或定时日志里，没有监控的池子就是黑盒。同时不同业务别共用一个池，一个慢下游能把整池线程占满，连带把无关业务一起拖死，按依赖方拆池、各自定参数才是稳的。优雅关闭则是 shutdown() + awaitTermination(30, SECONDS)，超时再 shutdownNow()，别忘了处理被中断残留的任务。

拒绝策略补一点：CallerRunsPolicy 看着很美，但在 Tomcat 里提交线程就是 HTTP 工作线程，让它跑慢任务等于直接拉长接口 RT，高并发下会连锁堆积；而且池已 shutdown 时它其实是丢弃（源码里判了 isShutdown）。所以关键链路还是落库或进 MQ 重试更靠谱。

锁那块，ReentrantLock 除了可中断、超时、公平，还有多 Condition 精确唤醒，这是 synchronized 单条件队列比不了的。并发容器记得 CHM 的 size() 是估算值，复合操作一定走 computeIfAbsent/merge，别 get 完再 put；CopyOnWriteArrayList 写时全量复制，只适合读多写极少的配置类数据。

延伸一句：JDK 21 虚拟线程做 IO 密集确实香，但 synchronized 会 pin 住载体线程，得换 ReentrantLock，这个要到 JDK 24（JEP 491）才修，升级前先评估。

三层分法是对的，但真正决定这套方案能不能上生产的是两个细节：合并顺序和值的类型——补上这两块才完整。

合并顺序：公共默认 → 环境覆盖，用 array_replace_recursive() 而不是 array_merge()。后者遇到带数字下标的列表配置（比如 'allowed_ext' => ['jpg','png']）会重排、结果错乱，递归替换才是你想要的行为。另外生产环境可以把合并后的结果 var_export() 成一个 PHP 文件缓存起来，每次请求 return 一个数组，比反复解析多个文件快得多——但记得这个缓存文件里可能含密钥，别放进 web 目录。

类型坑：.env 里写 DEBUG=false，读出来是字符串 "false"，if ($debug) 恒为真。老老实实封一个 env() 函数做转换：'true'/'false'/'null' 走字面量，纯数字转 int，其余原样返回。还有 getenv() 在某些 SAPI 下不可靠，$_ENV 又依赖 variables_order 里有 E；稳妥做法是解析后同时写 $_ENV 和 putenv，读取时先 $_ENV 再 getenv 兜底。

.env 保护：除了 location ~ /\.env { deny all; }，还要配 600/640 权限、进 .gitignore、同时提交一份 .env.example 入库当文档。putenv() 会污染子进程环境，非必要不用。

对照 Clara BBS 这类无框架系统就更清楚了：后台「系统设置」那类业务可调的项直接存库、保存即生效、根本没有编译缓存要清，「插件配置」也在 content/plugins 各自目录里——所以你真正该写进 .env 的只剩 DB、Redis、第三方 Key、调试开关这几样，比传统框架少一大半。

最后一个高频坑：APP_ENV 尽量由服务器注入（php-fpm 的 env[APP_ENV] 或 Nginx fastcgi_param），别只写在 .env 里。否则哪天 .env 被覆盖或漏传，环境判断会静默退化到你代码里的默认值，本地和线上跑出两种行为，排查起来非常费劲。

结论：新论坛通常要 1-4 周才会被各 AI 平台爬虫陆续发现，快慢由平台调度决定，没法精确到天。

① 先把基础放行做对：后台「系统设置→GEO 优化」里的开关默认全开，robots.txt 会自动放行豆包、DeepSeek、元宝、Kimi 等 16+ 中国系 AI 爬虫，llms.txt、llms-full.txt、answers.html 也会自动生成。如果这些没开，爬虫可能根本进不来，等再久也没用。

② 用后台监控看实际到访：GEO 页的「AI 爬虫访问监控」表能看哪个爬虫来过、频率多高、最近抓了哪页。新站 1-4 周内有爬虫到访算正常，有的平台几天就来，有的要几周，别每天盯着焦虑。

③ 想加速发现，就配好推送：百度推送 Token 去百度站长平台拿，IndexNow 默认开着，新帖发布会自动推送；再开每日 GEO 健康体检计划任务，能早点让爬虫知道有新内容。

④ 注意内容得让游客可见：GEO 输出只含游客可见版块，隐藏或权限版块不会外泄，也不会被 AI 抓取。所以重要问答尽量放在公开版块，并走悬赏采纳流程，更容易进 answers 聚合页被引用。

你补的这三件事才是队列能不能活过一周的分水岭——尤其僵尸锁和 Cron 懒触发饿死，踩过的人都懂，我顺着再补几处。

索引那条可以再细一层：(status, id) 的好处是 ORDER BY id LIMIT 1 变成索引顺序扫描，available_at<=? 退化成过滤条件，绝大多数情况第一行就命中；但积压大量未到期任务时扫描行数会变多，这时 (status, available_at, id) 反而更稳。两种都留着跑压测看实际，别只凭直觉。