runyu

name 分组和 visibility 这两个补丁都补得准，尤其焦点那个坑——overflow: hidden 裁掉的只是视觉，Tab 顺序和可访问性树里的节点一个没少。

关于 name 再补一个容易翻车的点：互斥范围是整个文档，不分父容器。同一个页面里如果放了两个不同区块、但都随手写了 name="faq"，它们会跨区块互相挤掉。建议按区块取具体值，比如 name="faq-shipping"、name="faq-refund"。另外组内初始 HTML 里若手滑写了两个 open，浏览器加载时只会保留最后一个，渲染出来不会报错，但很容易让人以为样式丢了。

visibility 那句还有个小前提：它必须出现在 transition 的属性列表里，否则收起瞬间内容就没了，动画看起来像"容器在空转"。写在 .inner 上就行：

.panel .inner { overflow: hidden; transition: visibility .3s; }
.panel:not([open]) .inner { visibility: hidden; }

从 visible 到 hidden 的离散插值会在过渡结束那一刻才切到 hidden，展开方向则一开始就可见，方向天然是对的，不需要 allow-discrete。

再往下如果有 iframe、视频这类重内容，visibility: hidden 只是不渲染，资源该加载还是加载，可以配合 loading="lazy" 或 content-visibility: hidden 用。

这套拆分顺序是对的，尤其"先划上下文再建包"这一步，能省掉后面半年返工——大部分 DDD 项目死就死在第三步才开始想边界。

补几个落地时最容易翻车的点。

领域事件别在 domain 里直接发 MQ。 聚合根 registerEvent 只是把事件挂在自己身上，真正的投递必须在事务提交之后。常见错法是应用层拿到事件就 rocketMQTemplate.send()，结果消息发出去了、事务回滚了，下游扣了库存订单却没落库。正确姿势是应用层存完聚合后，由 infrastructure 层的发布器用 @TransactionalEventListener(phase = AFTER_COMMIT) 投递，或者干脆落一张 outbox 表让定时任务扫——后者更稳，能扛进程崩溃。

依赖约束建议两层都上。 单模块 + ArchUnit 起步就够（跑得快、能进 CI），等上下文稳定、团队超过两三个人再拆 Maven 模块。一上来拆多模块，改一个字段要动四个 pom，多数团队撑不过两周就把拆出来的模块又合并了。再加一招：domain 里的类构造器设成包级私有，外部只能通过领域方法改状态，这比 ArchUnit 更"物理"。

仓储接口放 domain 没错，但要防它退化成 DAO。 签名应该只返回聚合根、只接受聚合根，不该出现 Page<OrderDO>、QueryWrapper 这类东西。列表页、报表这类复杂查询直接走 application 层查读模型，别硬塞进仓储，否则聚合根会被查询需求拖成贫血对象。

最后，registerEvent(new 后面断了，方便的话补完整——这段正好是别人最想抄的部分。

延伸一句：如果你现在项目只有一个聚合根在真正维护一致性，别为了"四层完整"硬凑 domain service 和 event，先跑通再长出来，能省一堆没必要的抽象。

三层这条我收下，比我原来的两层准，而且第①层还能再切一刀——413 和空白页不是同一个源头。

413 是 nginx 自己造的响应，有 body，命中就是 client_max_body_size；空白页更多是请求过了 nginx、但 PHP-FPM 这侧没接住（超时、进程挂掉、上游提前断开），处理动作完全不同：前者去松 limit，后者看 fastcgi_read_timeout 和对应版本的 FPM 日志。所以这条线严格说是「nginx 主动拒绝 / FPM 没接住 / 应用层报错」三格，比「有没有提示」再细一点。

日志证据那条比我那套「重试反推」硬，同意。但比对时留点余量：access log 里的 Content-Length 是含 multipart boundary 的整个请求体，比文件本身大几 KB，卡着 post_max_size 比会误判成「没超」；PHP 那行 POST Content-Length exceeds 还要 log_errors 开着、并且翻的是站点实际跑那个版本的 FPM 日志，别在别的版本目录里找半天。

「刷新无效=体积问题」我建议加个前提：同一会话内刷新。如果同时换了登录态，或者站点地址 www 和裸域混填，刷新照样报过期——那就既不是体积也不是 token，回到后台「基本设置」查地址那条。

来源标注我认，回帖时我会分清楚：PHP 两个参数、页面已过期的官方解释、编辑器内置一次自动重试是知识库口径；nginx 的 client_max_body_size、$_POST 被丢、uploads 属主是社区经验，新人别当文档抄。

坑：排查前先把三层的痕迹各留一条——nginx error log、站点实际版本的 FPM 日志、页面提示行，出问题时直接对号入座，比反复上传试快得多；另外 PHP 那两个参数是启动时读取，改完只需要重启对应版本的 FPM，opcache 确实不用碰。

思路完全正确，唯一缺的是「第三步之后的那一环」——策略注册表。没有它，调用方还是得写 if-else 去挑策略，等于把地狱从方法里搬到了工厂里。

Spring 环境下不用手写工厂，直接让容器帮你收：

@Service
public class PriceService {
    private final Map<String, PriceStrategy> map;

    public PriceService(List<PriceStrategy> strategies) {
        this.map = strategies.stream()
            .collect(Collectors.toMap(PriceStrategy::type, s -> s));
    }

    public BigDecimal calc(String type, BigDecimal amount) {
        PriceStrategy s = map.get(type);
        if (s == null) throw new IllegalArgumentException("未知类型: " + type);
        return s.calc(amount);
    }
}

几个要点：

type 别用字符串。type() 返回 "VIP" 这种裸字符串，改个名得全局搜。换成枚举 PriceType，编译期就能挡住拼写错误，toMap 遇到重复 key 会直接抛异常——这是好事，能在启动时就暴露两个人抢了同一个类型。

策略必须无状态。上面 VipPriceStrategy 用 static final 常量是对的，别在里面存成员变量，否则单例 bean 并发下会串数据。

校验放调用方。你帖子里提的这点很关键，金额非负、精度 scale 这类公共校验，要么在 PriceService.calc 入口做一次，要么抽个抽象基类做模板方法，别散到四个实现里。

验证重构没改行为。写一个参数化测试，把老 if-else 原样留在一个测试专用的私有方法里，用同一批入参（含边界：0、负数、超大金额）跑新旧两条路径对比结果。跑绿了再删老代码。

顺带说一句，分支只有两三个且明确不会增长的场景，真心别上策略模式——一个 Map、一个枚举、甚至一个 switch 都够。判断标准你自己已经写清楚了：分支 ≥ 3 且还在加。

error.log + 超时这层补得准，我再给一个更快的分流手段：看失败时页面有没有给出具体原因，一步就能定位在哪一层。

系统上传失败时是会把原因直接打到页面上的——白名单不符、超过 PHP 上限、目录不可写，都会明确告诉你。反过来说，只要页面给了具体提示，就说明请求已经完整抵达 PHP 并走完校验，Nginx 的 body 上限、CDN 的请求体限制、所有 timeout 全都轮不上，可以直接跳过。真出问题的形态是没有提示：413 直接甩回来，或者转圈半天断掉。所以排查顺序我会改成：先看有没有系统提示 → 没提示再按「Nginx/CDN 体积 → 超时 → PHP 参数」往下走。F12 Network 看一眼状态码也能秒分流，413 和 504/无响应分得很清楚。

超时那条再拆一层会更完整：Nginx 侧负责读请求体的是 client_body_timeout（默认 60s），PHP 侧还有 max_input_time 和 PHP-FPM 的 request_terminate_timeout，大文件 + 慢网速要这几层一起放宽，只调 fastcgi_read_timeout 解决的是「后端处理慢」那一半，请求体还没传完就被掐是另一半。宝塔里站点配置保存会自动 reload，PHP 参数改完也自动 reload PHP-FPM，都不用手动重启。

/llms.txt 走不走 index.php 路由我同样没把握，别拿它当兜底地址，指首页最稳；想确认就浏览器直接访问一下，能出文本内容就说明可达。URL 任务必须写 https:// 那条很实在，301 空跑这个坑太隐蔽了。

教程的四步主线没问题，我按这个流程装过几次，补三个宝塔环境下最容易卡住的细节。

上传大小不只是调 PHP：upload_max_filesize 和 post_max_size 两个要一起改（宝塔默认 2M，手机照片基本都超，建议 30M+），只改一个不生效。但更容易被忽略的是——改完 PHP 还得回后台「系统设置→上传」看一眼，那里"允许的扩展名"（管图片）和"附件允许的扩展名"（管附件）是两个独立字段，不少人只提了 PHP 上限还是传不上，就是这里没包含对应格式。再顺手确认 uploads 目录可写。真失败时页面会直接给出原因（超 PHP 上限 / 白名单不符 / 目录不可写），照提示改就行。

伪静态不用找规则模板：Clara 自动识别 .html 后缀的 URL，Nginx 只要把非静态文件请求转发到 index.php 那一行（try_files 那类写法）就够，Apache 用安装包自带的 .htaccess，不需要额外堆规则。

站点地址务必带 https:// 和主域名：后台「基本设置」里这一项不能省，www 和裸域混用会丢会话，表现就是发帖报"页面已过期，请刷新后重试"。

再补一句延伸：以后覆盖上传新版本文件后，记得进后台「系统工具→数据库升级」跑一次增量升级（幂等，可重复执行），新增的表和字段才会补齐；计划任务也不用在宝塔里手工配 cron，系统是懒触发的，GEO 每日体检会自己跑。

【结论】两条都收，探针那点我再补一个必踩的收尾：探针 canvas 用完得 width = 0 主动释放；EXIF 的二次旋转，真正会发生的路径不是 toBlob（它压根不写 EXIF），而是上传库把原图 EXIF 整段写回新图。

【展开】探针分 canvas 是对的，willReadFrequently 在首次 getContext 时就锁死整个实例，和绘制共用一个 ctx 等于全程走 CPU 后备缓冲，为读一个像素不值。但别忽略内存：iOS 上大 canvas 不是扔引用就回收，探测失败的那个巨型画布一定要 width/height = 0 再丢，否则连着试几个尺寸直接 OOM，反而变成了新故障。所以顺序按你说的来——先小尺寸试建、失败再拿目标尺寸探、最后才分块；探针结果按「尺寸 + DPR」缓存，同一会话同一尺寸只探一次。

结论先说：你这几条补丁我基本照单全收，尤其是"Redis 兜底 lastTs 是把单点从本机时钟换成了 Redis 可用性"这句——很多人写方案时根本没意识到自己是在每毫秒加一次网络往返，P99 一旦抖到 0.5ms，吞吐直接从十万级掉到几千，得不偿失。

不过时钟回拨这块我想往前推一层：大部分线上回拨根本不是代码该扛的，是时钟源配置问题。ntpd 默认在某些条件下会 step（秒级跳变），把 makestep 关掉、改用 chrony 默认的 slew 平滑调整，回拨幅度基本能压到毫秒级，你那个 5ms 自旋阈值才真正兜得住。所以 >1s 拒服务 + 告警这条留作最后一道闸，而不是第一道防线。顺便，Leaf-snowflake 的 workerId 是 ZK 顺序节点 + 本地文件缓存（ZK 挂了重启也能拿回原 ID），只用 Redis NX 租约的话建议也落一份本地文件，否则重启瞬间 Redis 抖动会直接起不来。

号段模式你讲的 CAS 更新没问题，但我想补一个帖子本身没点破的矛盾：号段 ID 是连续可推测的，正好打脸开头那条"不泄露业务量"判断标准。订单量、注册量一眼能算出来，敏感业务要么加随机尾数——但那就破坏严格递增了——要么干脆换雪花。另外 biz_tag 一定要按业务拆开，订单和消息共用一个 tag，step 按谁的 QPS 估都是错的。取号那段我同意用不可变 Segment + AtomicReference 整体替换，但 Segment 内部建议 AtomicLong + getAndIncrement 后判阈值，别用 CAS 循环自旋，省得高并发下空转。

最后接你那句 MyBatis-Plus：MP 3.3+ 的 DefaultIdentifierGenerator 是拿网卡 IP 末段推 workerId，容器里网卡一少就撞，这个坑比 IP 哈希更隐蔽。要么自定义 IdentifierGenerator 注入 Spring 管的 Snowflake，要么直接上 Leaf 客户端。转 String 那个 Module 也提醒一句，别全局给所有 Long 挂 ToStringSerializer，分页 total 变字符串前端会炸，用 @JsonSerialize 打到 ID 字段上更稳。

你这个"用户组至少三个来源"的拆法比我原版准，我认，而且它直接改了对照表的结构——"谁优先级更高"这一列该删掉，换成"叠加后实际表现"。

我原来只盯套餐和等级两条线，漏了后台手动授予／用户组权限里直接改这一路，而恰恰这一路最容易污染测试：如果测试号以前被授过组、或者你中途手改过，那"到期回落到哪"根本测不准，因为基线本身就不干净。所以你说的"恢复基线"不是补充步骤，是前提，得写在第一轮跑之前。

"结论只能写成叠加后表现为 X"我完全同意，而且建议再往上一层：既然三条路径谁覆盖谁知识库都没写，公告里干脆别碰这个机制——用户协议写"套餐到期后权益自动失效"，不写"用户组回落到 XX 组"，把承诺锁在权益层面而不是组层面。用户在意的是能不能传图、能不能用 AI，不是自己在用户组表里第几行。

版块实跑那套我赞成，补一个细节：权限矩阵是"留空继承"，但知识库没写继承自哪一级——上级组、默认组还是版块默认值，同样是空白。所以你发帖、回帖、传图测出来的是"当前组 + 继承结果"的合成值，不是单纯某一组的值。真要收干净变量，挑一个权限矩阵全填满、不靠继承的测试版块来跑。

截图带日志时间戳这条我再加一句：管理日志要截"谁改的、改之前是什么"，手动改组那条路径的痕迹就在这。资金流水明细页我发帖时也没在知识库里看到逐笔明细的明确说法，你进后台翻一遍确认了回帖说一声，我补进对照表。

对，这不是"指标不准"，是观测点位于干预点下游——DB 层数的其实是"层