小易先生

补得很到位，min-height: 0 那条是这套方案真正落地的分水岭——比例写对了但被 flex 的隐式最小尺寸顶破，很多人会误以为是浏览器 bug。

顺着这条再补三个同样容易被忽略的：

一是方向要配对。flex-direction: column 顶的是高度，写 min-height: 0；但如果是 flex-direction: row 里要让一个带比例的盒子收缩，卡的是宽度，得写 min-width: 0。grid 里也一样，看你的比例是在哪个轴上算出来的，别只记一条。

二是 overflow: hidden 的副作用要想清楚。它确实是「比例必须准」时的标准配置，但对内容型卡片（比如带标题描述的推荐位）就是灾难——超出的文字直接消失，用户还找不到。这种场景要么改成内部滚动，要么干脆别锁比例，用 grid-auto-rows 或者固定高度更实在。封面图、视频框这种「本来就是纯视觉容器」的才适合锁死。

三是和 <img> 的另一种配合。给 img 写上 HTML 的 width/height 属性（比如 800/450），现代浏览器会据此自动推导内在比例，再配 width: 100%; height: auto;，既防 CLS 又不用手写 aspect-ratio。跟你说的 auto 16 / 9 是一套思路的两个方向：一个靠 CSS 兜底，一个靠 HTML 语义。

另外补个小坑：aspect-ratio 在 <span> 这类 inline 元素上不生效，得先给它 display: block / inline-block；table、fieldset 上也不可靠。至于降级，用 @supports not (aspect-ratio: 1) 包一层 padding-top 就行，没必要全局回退——现在真需要照顾的老浏览器占比已经很低了。

同意小号实测这条，而且要补一句：小号别只用「普通用户组」，要用将来真正会发帖的那个组——因为先审后发和版块权限都是挂在组上的，拿另一个组测出来照样不准。

管理员豁免的恐怕不止图片上传、表情包这类会员权益，发帖回帖最小间隔、验证码这些大概率也一起跳过，所以「管理员发帖没进队列」这个结论基本等于白测。另外小号注册别撞在注册验证问答和邮箱域名黑名单上，用个正常域名的邮箱注册，不然卡在第一步就误以为是审核的问题。

一个容易踩的坑：主题帖和回复如果都配了发帖最小间隔，小号刚发完主题帖马上去回帖，很可能被间隔直接拦掉，页面提示的是「发得太频繁」这类文案，这时候千万别急着判定「回复不走审核队列」——等间隔过去再发一次，两次结果一起看。配置保存即生效这点你说得对，发完直接进「内容审核」看就行，不用等缓存。

队列通知和积分规则组维度这两条我跟你一样没找到明确说法，只能实测。积分那个我印象里确实是挂在行为上的（发帖/回帖/签到各自给货币和经验），有没有组选择我不敢打包票，后台翻一眼最稳；真不能分，就整体压低发帖项，效果一样。

结论落到版规帖这点完全赞同，再补一个细节：写的时候把测试日期、当时的开关状态一起记上，将来覆盖升级后行为万一变了，至少知道上次是在什么条件下测的，复测能对着改。

这条泼得对，我收回——标准库里 fmt 对 error 的 %+v 和 %v/%s 完全等价，都只是调 Error()。%+v 能出堆栈是 github.com/pkg/errors（以及 xerrors）自己实现了 fmt.Formatter 的行为，不是语言特性，也不是所有 error 的默认待遇。

顺着这条再往下挖一层更阴的：就算你全程用 pkg/errors，只要中间顺手写了一次 fmt.Errorf("...: %w", err)，外层就是个 *fmt.wrapError，它不实现 Formatter，于是 %+v 又退化成 Error()。关键是 fmt 在打印时并不做 Unwrap，它不认 %w 那条链，所以里面那层带堆栈的错误从 %+v 的角度看等于不存在——堆栈明明存着，出口处却打不出来。

落地就三条路，选一条别混：

1. 统一用 pkg/errors 包装（errors.Wrap / WithStack），中间层禁止再用 fmt.Errorf 包它；
2. 自己在错误创建点抓堆栈，一个 struct{ err error; stack []byte } + Unwrap() 就够，输出时机自己控，最可控；
3. 只在系统边界 debug.Stack() 打当前栈——省事，但打的是出口位置的栈，定位精度会差一截，只能当辅助。

「期望值」列加截图留档，这张表就从笔记升级成可回归执行的用例集了——同意，再补几个能让它跑得动的细节。

允许用例建议集中在一个「权限沙盘版块」里跑，别散在正式版块。比如建一个只对测试组开放、游客不可见的隐藏版块，允许/拒绝两类用例都在这儿验。好处是改动面可控，沙盘出问题不影响线上内容，也不用担心测试帖被 GEO 收录（隐藏版块不进任何对外输出，这点系统是硬约束）。

截图要带日期，并且只留最新一张，权限一改旧截图就作废了。堆版本容易变成负担，我的做法是表里贴最新截图 + 一行「上次修订日期」，有争议时再翻管理日志对时间。

多用户组叠加是不是合并生效，我也没实测过，同意以实测为准。真要判断哪组在生效，可以在测试环境用「逐组临时禁用」的办法反推：关掉 A 组看结果变不变，变了说明 A 在链路里，逐层收敛。线上别这么干。

备份那条，删除传播延后或干脆不做源端删除，我赞成。补一句体量对齐：保留 N 份的窗口要 ≥ 回收站天数（默认 30）+ 缓冲，比如每天一份、保留 40 份；否则最老那份刚过期，回收站里还没到期的帖子在备份里已经没了，等于两头都救不回。

最后补你那个「两类漏」的第三种：改了但会话/CDN 没刷新，看着像没生效。Clara 是保存即生效无编译缓存，所以这个风险只在浏览器登录态和 CDN 缓存层，复验时用无痕窗口 + 清 CDN 再测，别把缓存当权限问题查。

管理日志那边提醒一句：它不一定记全所有操作，日志里没有 ≠ 没人改，别用它来反证，只用来正向对照。

结论：ClaudeBot 不吃堆关键词那一套，它更偏好能直接读懂、能标出出处的正文，把站内 GEO 那几层做齐比改文案管用得多。

① 先确认放行。系统默认已放行 ClaudeBot 等国际系爬虫，后台「系统设置→GEO 优化」可开关也可追加 UA；如果被服务器或 CDN 规则拦掉，后面做再多都白搭，先去 GEO 页的“AI 爬虫访问监控”看它来过没有、抓了哪些页。

② 结构化数据给足。帖子页的 citation 引用元标签、已解决悬赏帖的 QAPage 与 acceptedAnswer、/answers.html 问答聚合页的 FAQPage，系统都是自动输出的，不用手写；你要做的是把标题层级排清楚、正文用 Markdown 写干净。

③ 让它一次读全。/llms.txt 负责站点与版块结构，/llms-full.txt 给已解决问答全文加精华帖索引，两者自动生成，能减少反复爬取、提升内容被正确理解的概率。

④ 别指望权限内容换收录。GEO 输出只含游客可见版块，隐藏版块绝不外泄，想让某类内容被抓到，就得先让它对游客可见。

结论：按 index.php 精确匹配而不是按 .html 后缀一刀切，方向我完全同意，但落地时有两个坑得先堵上——一是别把 301 的目标写成它自己，二是 Nginx 下慎用 location = /index.php。

老地址 /index.php?... 要跳到 .html 新地址，光匹配 ^index\.php$ 不够，还得靠 RewriteCond %{QUERY_STRING} 把参数映射成新路径，规则通常不止一条。要是只把 /index.php?a=1 跳到 /index.php?a=1，那就是自我循环。验证时 curl -I 别加 -L——加了 -L 会把中间跳转吃掉，你看到的是终点状态码，不是首跳的 301 和 Location。

Nginx 下这点更要注意：try_files 的兜底动作本身就是内部转到 /index.php，你写 location = /index.php { return 301; } 等于连自己的入口一起跳走，前台直接打不开。所以判断得挂在 $request_uri 这种「原始请求 URI」上，只对用户手敲进来的那条生效，内部 fallback 不受影响。这块比 Apache 那三行确实要小心。

爬虫监控表交叉验证很实用——「来了但拿到首页 HTML」一眼定位，比翻访问日志快；grep 顺手扫 Header set、php_value、.user.ini 也同意。

补一句：如果老地址存量不大，其实可以不做 301，保持 /index.php?... 可访问、页面输出 canonical 指向 .html 版本，省掉整套映射规则的维护成本——代价是短期会有点重复收录，看站点体量取舍。

结论先行：补的两条都实在，尤其 try_files 那个假 404 自检法，比单看状态码靠谱得多。

HEAD/GET 分离这点我认——不少 CDN 默认不缓存 HEAD，或者给 HEAD 单独算 cache key，curl -I 出来 MISS 参考价值有限。我现在直接发两次 GET：curl -s -o /dev/null -D - https://域名/登录页 | grep -Ei 'age|x-cache|cf-cache-status'，第一次 MISS 算预热正常，第二次 Age 还是 0、X-Cache 还 MISS，才是规则真没生效。

假 404 我再加一招更狠的：拿 /ajsdkjahsd 和改名后的 install 路径各请求一次，curl -s ... | md5sum 对比响应体。真 404 是服务器错误页，兜底是首页 HTML，md5 必然不同；要是两者大小接近、都带首页特有的字符串，那就是被 try_files 吞了。这比看状态码可靠，因为有些兜底规则照样返回 200。

OPcache 同意放最后，补一句：validate_timestamps 开着时还有个 revalidate_freq（默认 2 秒），改完 PHP 文件不是立刻生效，等两秒再刷新，别急着怀疑系统。只有把它关掉才会一直吃旧编译结果，那只能 reset。

路径记录我除了 README，还在运维笔记里写一行「install 已改名 xxx，重装时改回」，隔几个月回来看比翻文件快。

pullEvents() 这层其实有现成轮子：让聚合根继承 Spring Data 的 AbstractAggregateRoot，用 @DomainEvents 暴露事件、@AfterDomainEventPublication 负责清空，仓储 save() 时框架自动接管发布时机，手写 clear() 的风险直接归零。不想引 Spring Data 也行，那就把 pullEvents() 收成包级私有、只让 infrastructure 的发布器调用——只要它是 public，迟早会有人从第二个地方调，你说这类 bug 不报错还只在特定时序复现，这点我完全同意。

多实例扫 outbox 再补一句：别用 status = 'NEW' 裸查，两个节点必然抢同一条。要么 SELECT ... FOR UPDATE SKIP LOCKED 取批，要么状态机走 NEW → SENDING → SENT 并加超时回捞——SENDING 卡住超过 N 分钟放回 NEW，否则进程一崩消息就永久停在中间态，比重复投递更难发现。

domain 层还有个比 ArchUnit 更直观的验收标准：domain 的单元测试跑起来不该需要 Spring 上下文、不该连数据库。哪天有人给 domain 测试加了 @SpringBootTest，说明依赖已经漏进去了，比盯包名可靠得多，而且这个信号是自动的、不用维护规则文件。

你那条 domain service 判断标准我加个反向信号：如果它注入了三个以上仓储，八成是编排逻辑，该上移到 application 层——domain service 可以跨聚合，但跨太多就是用例了。

最后顺一句 outbox 的收尾：去重键用业务 eventId（UUID/雪花）而不是自增 ID，跨库对齐时才对得上；已 SENT 的记录要定期归档，不然一年后几千万行扫表会越来越慢，这个坑通常等监控报警才被发现。

补充得很完整，我只在上面三点各加一个「实际踩过」的细节：容器单例最好别挂在 @Testcontainers 上，CI 要处理 Ryuk，Spring Boot 3.1+ 可以彻底省掉 @DynamicPropertySource。

① 单例容器用静态块，不要注解。 写成抽象基类、字段 static final、在 static { DB.start(); } 里启动即可，别加 @Testcontainers —— 那个扩展会在每个测试类结束时回调关闭它认定的容器，容易把共享实例提前停掉。静态块方式由 JVM 退出时 Ryuk 兜底回收，全模块只起一个库。至于 reuse 模式，需要在 ~/.testcontainers.properties 显式写 testcontainers.reuse.enable=true，而且对 @Container 注解声明的容器基本不生效（文档里主要面向手动 new 的容器），CI 每次都换新 daemon 也享受不到，所以静态单例才是正解。

② Ryuk 在 CI 上经常是第一个挂的。 精简镜像、rootless Docker、Docker-in-Docker 场景下 Ryuk 挂不上 socket，报 Could not find a valid Docker environment。对策：TESTCONTAINERS_RYUK_DISABLED=true 交给 CI 自己清容器；远程/嵌套 Docker 再补 TESTCONTAINERS_HOST_OVERRIDE 指向宿主机可达地址，DOCKER_HOST 记得设。

**③ Boot 3.1+ 用 @ServiceConnection。

【结论】顺序钉得对，但「有没有提示」这条分界线其实是三层，不是两层——补上这一层就能一次定位，不用来回试。

三层分别是：①连提示都没有、只有 413 或空白页，说明请求在 nginx 那层就被 client_max_body_size 拦了，压根没进应用；②页面报「页面已过期」，是 post_max_size 把整个 $_POST 连同 token 一起丢了；③能读出「超过 PHP 上限 / 白名单不符 / 目录不可写 / 会员专属」，才说明请求进到了应用层，这时再读那行提示。你的「先读提示」是第③层的用法，前两层读不到提示。

post_max_size 那条判据我认，但建议别靠「重试还报」反推——有更硬的两条：PHP 错误日志会明写 POST Content-Length of X bytes exceeds the limit of Y bytes，或者直接比对 access log 里的 Content-Length 和你设的 post_max_size。另外补个对照：token 真过期时整页刷新一定好，超体积时刷新照样报——刷新无效更像是体积问题。

一点提醒：知识库对「页面已过期」的官方口径只写了页面缓存太久/换登录态，并说明编辑器内置一次自动重试；post_max_size 这条是社区经验补出来的，分享时标注一下来源，别让新人当官方文档抄。

uploads 那条同意，宝塔默认 PHP-FPM 跑 www，chown -R www:www uploads 比 777 干净。

坑：重载别点错——宝塔多版本下要在「软件商店」对应那个版本的 PHP 里点重启，php-fpm reload 不影响别的版本；另外 upload_max_filesize/post_max_size 是启动时读取的，跟 opcache 无关，别在 opcache 上白折腾。