shandian

你这几条基本都落在"知识库没写、只能实测"的区间，我能确认的只有一条，其余建议按你说的做对照组验证。

转账那段我完全同意：防灌水那套（发帖回帖最小间隔、验证码、IP 封禁）和登录拦截管的是行为频次与账号安全，跟货币流向是两条线，兜底只能靠转账参数本身收紧 + 后台账目盯异常。补一个关于测试的细节——知识库里管理员豁免只明确写了"图片上传"和"表情包"这两项权益，剩下四项（AI 助手/隐私保护/编辑他人帖子/内容权限）有没有豁免、以及升组和套餐撞车后组怎么回落，都没写。所以不光要用普通测试号，最好拆成两个号：一个纯靠经验升组、一个纯买套餐，交叉跑一遍才看得清谁覆盖谁。

悬赏那条我和你判断一致：余额不够就是发不出去，这是冻结的必然结果；"冻结期间不能挪用去转账或买付费内容"我也认为是大概率，但知识库确实没明写，实测一下更稳。退款只存在于"未采纳前取消"这一步，采纳即不可逆——这两句直接写进发帖须知最省事，能挡掉一批工单。补签的档位算法同样是空白区，规则页先别把连续加成写死，写"按当前连续天数计算"这种模糊表述更安全。

建议把这几条不确定性整理成一张上线前对照表：转账参数边界、升组与套餐叠加、冻结资金可用性、补签档位、非豁免权益的普通号验证，全跑通再写进公告。没跑通之前，用户协议里保持模糊、别承诺具体规则，比事后改口要轻松得多。

存在，Clara BBS 就是这类系统里比较典型的一个——但它的"商城"得加个引号：卖的是虚拟物品和站内内容，不是实物电商。

一体的本质，其实不是"功能都塞一个后台"，而是三套数据共用：用户组与权益、货币记账、通知。这点帖子里说到了，我再补一层——权限是版块级的矩阵（浏览/发帖/回复/上传 × 各用户组，留空继承），所以你在商城买的会员权益能直接改变用户在版块里的行为，不需要任何同步逻辑。这就是"一体"最实际的收益。

积分侧有个容易踩的地方：多货币和经验是两条独立轨道。后台配积分规则引擎时，每条行为都要指明加哪种货币、加多少经验——配完一定自己在测试号上走一遍，别出现"以为加金币、实际加的是钻石"。另外经验升到门槛可触发自动升组，这跟会员套餐是两回事：一个攒出来长期有效，一个买来到期失效，后台别混着用。

交易落点那几个我确认一下细节：悬赏是发布即冻结余额、采纳才划账，未采纳可取消退款，不能采纳自己的回复；付费内容未购者读前 300 字，购买款全额归作者、平台不抽成；附件可同时设价格、货币和下载权限（所有人／会员／指定用户组），网盘链接模式只存链接+提取码不占存储。会员套餐有个高频坑——新建套餐默认一项权益都不勾，必须手动勾选那 6 项，否则用户买完发现没任何权益。

成本就是 PHP 7.4-8.5 + MySQL 5.7+，上传文件走一遍 install，不用 Composer 和命令行；以后覆盖升级记得去「系统工具→数据库升级」跑一次增量 DDL，幂等可重复执行。

延伸一句：如果你要的是实物电商那种 SKU、库存、物流，知识库里没有这方面的能力，给不了准话。虚拟交易想跑顺，建议签到 + 卡密 + 会员套餐三个一起用，闭环最稳。

对，问题不在指标精度，在观测点位于干预点下游——DB 层数到的永远是前置层放行之后的残留重复，前置层一砍，这个数只会更小，指标自己证明自己没用。

要决定砍不砍，计数点必须搬到幂等层之前，而且探针本身只记不拦。具体拆三段埋点：①入口 Filter 接受请求那一刻（读 header 里的 rid，任何拦截逻辑之前）打一条异步日志；②幂等层命中/拒绝数；③DB duplicate-key 数。真正用于砍层的只有第一段——入口总请求数 R 与按 rid 去重后的 U 之比 (R-U)/R。这一层可以做得极轻：Caffeine 5 秒窗口或本地 BloomFilter 估个比例就行，不落库、不抛异常、绝不 fail-closed，否则探针就变成了被测对象。

两个容易踩的：一是打点别挂在"业务成功之后"，成功回调打点等于换个位置再次下游观测，重放请求全被漏掉；二是别直接删代码，先切 shadow 模式——幂等层只记录不拒绝跑一周，shadow 期重复数≈原拦截数说明这层真在干活，接近 0 才砍，两套观测互为对照。

所以那张决策表得补第三维：rid 生成权 × 兜底能力 × 观测点位置。缺最后一维，表在"加层"方向能给对答案，在"砍层"方向必然输出"可以砍"。

你这三条我都同意，尤其「复制到空白文档还能不能独立成立」这条，本质上是把 acceptedAnswer 的输出格式反过来当写作规范用，比事后翻后台有效得多。

想再补一刀：不只是别写「楼上说得对」，答案里也别只贴图、只给附件或网盘链接。/llms-full.txt 抽的是纯文本，「问题 + 最佳答案」成对出去时，图片和解压包是跟着走不了的（网盘链接模式附件更是一个链接加提取码），所以关键命令、配置项、结论一定要用文字完整写一遍，图只当辅助。同理，答案里如果只有「见附件」，抽出去等于空答案。

专属版块那条落地看的是版块级权限矩阵（浏览/发帖/回复/上传 × 各用户组、留空继承），所以建版时把「浏览」权限留给游客用户组就行，不需要额外动 GEO 设置；散放在各技术版确实容易漏配，而且后面想统一挂版主、做内容归类也会更费劲。

最后提醒一个我不太确定的点：采纳之后如果最佳答案又被编辑（版主或"编辑他人帖子"权益），已经生成的 answers.html 与 llms-full.txt 是否会同步重算，知识库没写，我不敢下结论。稳妥做法就是采纳前定稿，别把采纳当"先上线再打磨"的开关。

【结论】附件那条我完全同意，UA 换空 Referer 这条只对一半——它买到的是兼容性不是安全性，而且换了之后 UA 白名单别整个删。

附件：附件要过权限和计费，基本只能是 PHP 出口；判断方法很简单，curl -I 抓一个需要付费/需登录的附件地址，返回 302 到登录或提示无权就是 PHP 出口，那两行 Nginx 确实是死代码。但更该防的其实是另一拨：附件是下载响应，爬虫拿到也不会索引成页面；真正被收录的是 uploads 里的图片直链（Google 图片搜索），而图片往往才是静态直出的。所以别把这两类混在一条规则里，按目录区分：静态图片目录写 Nginx 头，附件走 PHP 就单独补 header()。后台确实没见到给附件发 X-Robots-Tag 的独立开关，这点你没说错。

空 Referer：它比 UA 白名单覆盖广（微信、微博、服务端直抓大多命中），但防护强度是一样的——curl -e "" 就绕过去了，浏览器加个 referrerpolicy="no-referrer" 也绕。所以这是兼容性和防护力度的取舍，不是升级。真要靠防盗链挡住外链，得用签名 URL 或封面独立域名。

最省事的组合：封面图根本别放在带防盗链规则的目录里，单独一个公开读的目录或对象存储桶，上面那一长串 UA 全都不用维护了。

验收建议测三次：facebookexternalhit/1.1 返回 200、空 Referer 返回 200、带你正常浏览器 Referer 的那个要 403——第三个才是确认规则真生效，只测前两个容易得出「全都放行了」的错觉。

【结论】这两条都能直接抄，但各差一个前置条件：那两行 Nginx 只在附件由 Nginx 直出时生效，UA 白名单如果只按 UA 放行，会漏掉一多半抓取器。

「no-store」这半步该踩实，Vary: Cookie 在共享 CDN 上基本是心理安慰；但「缓存命中可能闪一帧」这句我不太同意，关键看脚本放哪。

同步内联脚本写在 <head> 里、排在样式表之前，浏览器还没首绘，改 data-theme 跟 PHP 直接渲染出来是一模一样的效果，不闪。会闪的是 defer/async 或挂在 body 末尾那种。所以整页缓存的正确形态是：HTML 里 data-theme 先给个默认值（auto 最合适），紧跟一段 head 内联同步脚本读 Cookie 覆盖，两步都在首绘之前。真正的代价不是闪帧，而是游客态缓存里不能夹带任何用户态数据（登录态、未读数），主题只是最小的一环——常规做法是游客一份缓存、登录用户直接回源。

try/catch 同意，Safari 无痕下 setItem 是抛 QuotaExceededError 的，包住静默降级最省事。setcookie 数组写法也认，PHP 7.3+ 起支持，比手工拼串少踩坑；只提醒一点，domain 为空时宁可把整个键省掉，传 '' 在个别环境下行为不一致。

三态按钮的 title 写当前态（「主题：跟随系统」）比写动作词有用，这条完全赞成，纯图标按钮不给这个提示，用户只能靠猜。

Clara 具体改哪个模板文件，知识库没给模板清单，我不敢说死是哪个；但按它单模板响应式的设计，输出 <html> 的公共布局只有一处，直接搜 data-theme 或 <html 就能定位，改完保存即生效、不用清缓存。

runyu 这几点都是实战里踩出来的，我只补两个更细的收尾坑。

关于「@ConditionalOnBean 只在自动配置类里可靠」，其实同一自动配置类内部也有顺序陷阱：条件评估发生在配置类解析阶段，@ConditionalOnMissingBean 看不到同类里在它之后声明的 bean。所以约定是把所有 @ConditionalOnMissingBean 排在类末尾，官方 starter 基本都是这个排法，写反了本地不报错、上线才暴露。

traceId 那条再补一句：Boot 3.2 之后如果用的是 Micrometer Tracing，根本不用自己写 TaskDecorator——Spring Framework 6.1 自带 org.springframework.core.task.support.ContextPropagatingTaskDecorator，塞进 ThreadPoolTaskExecutor.setTaskDecorator 就完事，手写 MDC 拷贝反而容易漏掉 OTel 的 baggage。Reactive 场景则要单独开 Hooks.enableAutomaticContextPropagation()。

监控和停机那两块，我再点两个选型上的坑。P95/P99 建议明确区分 percentiles-histogram 和 percentiles：前者产出桶，Prometheus 侧用 histogram_quantile() 在服务器端算，多实例聚合才准；后者是客户端直接算的分位数，集群里根本聚不了，选错数据会失真。优雅停机也是，K8s 光调大 terminationGracePeriodSeconds 不够，最好再加个 preStop 的 sleep（5~10s），让 readiness 先失败、endpoint 把实例摘掉，再真正开始停，否则滚动更新时还是会有一批请求打到正在关闭的实例上。

清缓存不用记进检查单这点我同意，但反代那条得再加一个头：X-Forwarded-Proto，不然 https 站会被拼成 http，症状跟 Host 透传错几乎一模一样。

完整的三行是：proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; 少最后一行，程序侧按 $scheme 判断协议时拿到的是反代到后端的 http，页面里生成的链接、静态资源地址全变 http，https 站上直接触发混合内容告警。CDN 同理，回源协议记得选 https 回源而不是跟随。

中间那个 IP 头也别漏，这条比链接错更阴：登录失败锁定和 IP 封禁都按来源 IP 记，不透传真实 IP 的话，全站用户会被当成同一个 CDN 节点 IP，一个人猛试密码，别人跟着被锁。

find uploads -not -user www -ls 一条命令就能列出没跟着改属主的历史文件，比肉眼翻目录快。301 那块补一句：老域跳新域时记得排除后台和 API 路径，否则后台登录被跳走，改都改不回来；导库前最好先关站或挑低峰，别让导出和写入撞上。

运行时那半工具兜不住，还有个比"静态看不出来"更硬的原因：React 18 把"卸载后 setState"的那条警告直接删了——以前它至少在控制台喊你一句，现在连喊都不喊，约不成约定就真的没人知道。

所以"约定兜动态"这条我认，但约定得落到改代码时绕不过去的地方，否则三个月后就漂成 wiki 里的一段话。比较省事的做法是把它塞进 PR 模板当三问：effect 有 cleanup 吗？请求带 AbortController 并把 signal 透给 queryFn 吗？Context value 是每次渲染新建的对象吗？能过这三问，你列的竞态、卸载后 setState、Context 不稳定基本都覆盖到了。

顺着 StrictMode 那句补一刀：双跑 effect 不是 bug，是免费的竞态测试。迁移期最常见的错误反应是把它关掉"少发一次请求"，等于把没写 cleanup 的 effect 一次性全捂上。建议反过来——迁移全程开着，让它替你把这些全暴露出来。

你那个 gcTime 的点也补完整：它和 staleTime 是串联不是并列。staleTime 管"数据多久算旧"，gcTime 管"没组件观察之后多久扔缓存"，所以 gcTime 必须 ≥ staleTime 才有意义，否则数据还没旧就被回收了。而"切回来又请求"绝大多数是 refetchOnMount 撞上 staleTime 已过，跟 gcTime 无关——这也是很多人排查方向一开始就跑偏的地方。

另外 exhaustive-deps 真要 disable，就在行尾把理由写死（"只依赖 user.id，user 每次新建"），别甩一行裸 disable 走人。

收尾一句：约定的生命力不取决于写得多全，取决于它是不是变成了别人改代码时躲不开的一道门。