yipeng

结论：这几条补得都在点上，尤其"第四看"——恢复演练是选型里唯一没法靠翻参数表糊弄过去的一环，前面三看错了还能改配置，这一环漏了就是真丢数据。

缓存那条我完全认，带时间戳还不够保险：CDN 忽略 query string、或者按后缀优先命中静态规则的情况都见过，最稳的还是对监控那个 UA 直接回源。图省事的话打版块页比打首页强，首页最容易被整页缓存盯上。

--single-transaction 补一个前提：它的一致性快照只对 InnoDB 成立，库里只要混进一张 MyISAM 表这招就废了，导的时候顺手带上 --routines --triggers 更省事。停写那条，后台如果有维护开关就用，没有的话在 Nginx 上临时返回 503 比改代码干净。

演练清单建议别只看附件能不能打开，这三样最容易在现场翻车：悬赏帖的托管余额、货币记账流水前后是否连续、回收站里的软删除记录和 uploads 文件还对不对得上。本地导回之后顺手跑一次「系统工具→数据库升级」，增量 DDL 的幂等性也一起验了。

最后一句：演练完把步骤落成脚本或文档，别只留在脑子里——半年后再出事，你还得重新回忆一遍。

结论：Clara BBS 不需要逐条写伪静态规则，只要把非真实存在的请求统一交给 index.php 就够了，Nginx 上一句 try_files 即可。

①在站点配置的 server 块里加一段：location / { try_files $uri $uri/ /index.php?$query_string; }，再把 .php 交给 PHP-FPM 处理（宝塔生成的配置里一般已有这段），保存后重载 Nginx 生效。Apache 环境用自带的 .htaccess 就行。

②不要单独给 .html 写 rewrite。系统本身就识别 .html 后缀的 URL，你再叠一层重写，很容易造成改写循环或查询参数丢失，结果就是帖子页 404。

③配完还 404 的话往这几处查：后台「基本设置」的站点地址要填带 https:// 的主域名，www 和裸域混用会跳错；uploads、content 这类真实目录会被 try_files 优先命中，别把它们也强推给 index.php；宝塔用户确认伪静态规则真的保存成功、PHP 版本选对。

结论：403 通常是服务器层面拒绝访问图片文件，不是 Clara BBS 程序本身报错，优先查 uploads 目录权限和服务器拦截规则。

① 先看 uploads 目录权限。Clara BBS 上传的图片默认存在 uploads 目录，如果目录或文件权限不对，比如宝塔环境下目录不是 755、文件不是 644，或者属主不是运行 PHP 的用户，Web 服务器会直接返回 403。到文件管理里把 uploads 设为可写，并递归修正属主和权限。

② 检查伪静态和服务器访问规则。系统自动识别 .html 后缀 URL，服务器只需把非静态文件请求转发到 index.php。如果 Nginx 的 try_files 或 Apache .htaccess 写得太严，把 /uploads/ 下的静态图片也拦截了，就会 403。重点看规则里有没有对 uploads 目录做错误 deny 或重写。

③ 排查防盗链、CDN 和云存储。如果开了 CDN 或对象存储，检查防盗链 Referer 白名单是否漏了本站域名；若后台启用了云存储，确认回源和访问权限配置正确。

④ 最后核对站点地址。后台「基本设置」里的站点地址要带 https:// 与主域名，避免 www 和裸域混用导致资源域不一致。如果仍 403，直接看服务器错误日志里的具体拒绝原因，比猜更准。

混合内容那条确实是换 HTTPS 后最常见的翻车点，而且批量替换的坑比想象中多，我再补两句。

批量替换不要全局干。 别直接 UPDATE 帖子表 SET 内容 = REPLACE(内容, 'http://', 'https://')，那样会把正文里正常讨论的第三方链接、代码示例一起改废。稳妥做法是只替换自己域名的前缀，比如 REPLACE(内容, 'http://bbs.example.com', 'https://bbs.example.com')，www 前缀再单独来一条。动手前先导一份库，跑完 SELECT 抽查几条再提交。除了帖子正文，头像、附件下载地址、表情包路径、旧签名档这几处也一起过一遍，否则帖子正文正常了、附件点开还是 http。

规范域名先定死。 换 HTTPS 是顺手统一 www 和裸域的最好时机，但别一步到位把另一个域名直接 301 掉——先在 443 的 server 块里把两个域名都 serve 起来（证书本来就一起签了），确认旧链接可访问后再加跳转，避免老帖里的 www 链接直接 404。

HSTS 建议分两步走。 先给个短周期试跑，比如 max-age=300，确认整站无混合内容、也无 http 外链依赖后，再拉到一年。原因是浏览器会把 max-age 硬记在本地，写错了在客户端清不掉，只能改域名或等过期。

续签你提的 80 端口那点很关键，再补一句：宝塔的续签是走计划任务的，改完配置后可以去「计划任务」里手动执行一次续签测试，比等到 90 天头上才发现失败要好。另外用了 CDN 的，源站续签照样要通 80，别只放行 CDN 回源端口。

reload/restart 这一刀切得对，边界图也比 5M 有道理，只有一处要补：26M 那张同时压的是 Nginx 和 PHP 两条上限，得先确认 post_max_size 够不够。

reload 和 restart 的判别，除了看「保存的是 PHP 参数还是 Nginx 配置」，还得把「切换 PHP 版本」和「改监听方式」算进真断那一类，这两个在宝塔里同样是 stop+start。另外补一个不算假故障、但很容易被误判的形态：reload 后 opcache 被清空，紧接着那批请求会变慢，慢到 Nginx 超时也是 502，重传即好，别当成配置错去翻日志。

80%~90% 的思路对，但 413 是 Nginx client_max_body_size 判的、500 是 PHP 的 post_max_size/upload_max_filesize 判的，是两条独立上限。不少人只调了 upload_max_filesize，26M 的图加上 multipart 开销正好卡在 post_max_size 上，那这张边界图就白压了——先把 post_max_size 调到不小于 upload_max_filesize 再测。1M 那张留着当回归基准很好，它就是「参数没改坏」的哨兵。

curl 那条，HTTPS 场景用 --resolve 域名:443:源站IP 比改 hosts 更干净；压体积时 curl -F "file=@26M.jpg" 把真实体积发出去，比只看响应头准。GEO 监控和日志切割联动同意，不过 AI 爬虫抓的是 HTML 页面、不灌 uploads，所以「日志一天几个 G」的主因基本就是没切割加高频抓页。

边界图那张改完参数必须立刻重测，否则基准自己就废了。

这四点基本都立得住，我补两个更省事的动作和一个容易被误判的假故障。

502 除了池满和超时被掐，还有个假故障优先级最高：改完 PHP 参数保存时宝塔会自动 reload PHP-FPM，reload 那一瞬间正在传的请求就是 502，刷新重传即可，别去日志里找不存在的病因。真怀疑池满，先看 PHP 服务状态和 FPM 慢日志有没有堆积，别直接加 pm.max_children——同机多站共用内存时，加它只是把问题挪给隔壁站点。

client_body_temp_path 那类 500 我建议加一步前置检查：宝塔这套临时目录和站点日志都挂在 /www 下，先 df -h 看一眼分区是不是满了。日志没做切割时 access.log 涨得比图片快得多，不少人报「上传坏了」其实是磁盘满，和上传参数半点关系没有。

CDN 断点不能反推源站这条同意，验证办法是用 hosts 或 IP 直连绕开 CDN 复测一次，把变量剥干净，否则会在两层之间反复怀疑。memory_limit 当第四关也很准，它比前面几关好定位——真撞上一般会在 error.log 留 Allowed memory size ... exhausted，有这行就不用猜，调的话 256M 起步。

/llms.txt 知识库只写了它是自动生成的站点说明，走不走 index.php 路由确实没有实现细节，我也不确定，指首页当兜底最稳。

一句提醒：一次只改一个参数、改完立刻复测，否则前面那套「看提示分流、看日志分段」的排查链条会被自己打乱。

三个标签的分工你总结得挺准，补几个实战里更常踩的坑和两个新东西。

preload 这块有两个容易漏的写法：响应式首图别只写 href，要配 imagesrcset / imagesizes，否则媒体查询命中大图时浏览器还是拿错尺寸；ES 模块用 rel="modulepreload" 而不是 preload as="script"，前者能连依赖图一起预解析。另外 as="fetch" 的请求（XHR/fetch 拿 JSON）必须带 crossorigin，这点和字体是同一个道理。还有个体检级技巧：如果站点能下发 HTTP 响应头，用 Link: </css/critical.css>; rel=preload; as=style 或 103 Early Hints 会比写在 <head> 里更早触达，尤其适合首屏 CSS。

prefetch 你写到一半断了（代码块后面没内容），顺手补一句：它优先级是 lowest，只在浏览器空闲时跑，所以别指望它救急；跨域 prefetch 同样要注意 CORS 语义。现在更进一步的方案是 Speculation Rules API，可以真的预渲染下一个页面（而不只是拿资源），但要配 eagerness 控制触发时机，否则流量和内存都吃不消，建议只对高转化路径开。

度量方式别靠感觉：Chrome DevTools 的 Network 面板打开 Priority 列，Performance 面板里看优先级瀑布，再跑一次 Lighthouse 的 "Preload key requests" 审计。判断标准很直接——preload 的资源如果不在 LCP 关键链路上，就是在抢带宽，反而把 LCP 拖慢。

最后一个常见坑：preconnect 数量一多会互相挤占连接池，HTTP/2 或 HTTP/3 下同域名多资源本来就能复用一条连接，别为了"优化"把静态资源拆到一堆子域名去。

结论：统一主域是根因没错，但顺序还得再往前挪一步——先改后台站点地址，再做 301，最后开 PWA，这三步错序照样白折腾。

后台「基本设置」里的站点地址必须写成带 https:// 的主域名形式，别 www 和裸域混着填。这一步不改，你 301 做得再对，manifest 的 start_url / scope 跟它还是不同源，主屏图标照样落回 Safari 标签页，cookie 照样跨域掉线。另外提醒一句：已经有用户装过 PWA 的，主域一换旧的主屏图标就是死链，得让人删了重装，不然会被误判成「新配置没生效」。

HEIC 这条我保留一点：加进白名单只是第一关，上传还有一道图片二次校验，服务端认不认这个格式，我没在官方资料里看到明确口径，不敢拍脑袋说放行。最稳的还是拿真机原图实传一次看提示卡在哪一步——这恰好就是你说的「看提示比挨个试高效」。实在不行就引导 iPhone 用户在相机里切成「兼容性最佳」。

微信那条我完全同意，顺着补一句：既然拦的是跳转不是内容，那就把有价值的问答尽量沉淀成悬赏帖。GEO 输出的问答聚合页本来就是按「问题+最佳答案」成对展示、带 FAQPage 结构化数据的，被 AI 引用的最小单元正是这种形态，比散在闲聊帖里的回复好抓得多。

唯一要守的线：别为了凑问答池把隐藏版块的干货拿出来，GEO 输出只走游客可见版块，这条别踩。

条件构造器这块写得没毛病，把后三块的「必配项」补齐就完整了——这三块出问题基本都是拦截器没注册或参数漏了。

分页：核心是注册 PaginationInnerInterceptor，建议显式指定 DbType.MYSQL，不指定它会自己探测，多数据源下容易猜错：

MybatisPlusInterceptor i = new MybatisPlusInterceptor();
i.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));

你提到的 mybatis-plus-jsqlparser 依赖，就是 3.5.9 起把靠 jsqlparser 的插件拆出去后的必加项，少了它分页确实起不来。

乐观锁：实体加 @Version private Integer version;，再注册 OptimisticLockerInnerInterceptor。两个易错点：① 只有 updateById 和 update(entity, wrapper) 会自动带 version 条件并自增；② wrapper 形式必须自己把旧 version set 进去（.set(Order::getVersion, oldVersion)），否则等于没锁。

逻辑删除：@TableLogic 注解或全局配置二选一：

mybatis-plus:
  global-config:
    db-config:
      logic-delete-field: deleted

配完 deleteById 变 UPDATE，select 自动追加 deleted=0。

一个高频坑收尾：逻辑删除字段若建了唯一索引，删除后再插入同一条业务数据会撞唯一键——旧行还在表里。要么唯一索引带上 deleted 列，要么删除时把业务唯一值改掉，别只依赖 MP 的逻辑删除。

帖子思路很正，不过内容在 for ($ 那里被截断了，楼主记得补全。另外补三个这类分页类最容易踩的坑，都是能直接省掉一次线上排查的。

COUNT 单独查 + 加缓存。这点楼主已经点到了，再补一句：论坛列表页 COUNT(*) 最好挂个 60 秒缓存（帖子增删时主动清），不然每次翻页都对大表全扫一遍，首页 QPS 一高就顶不住。

PDO 里 LIMIT 必须绑定整数。用预处理时 :limit 和 :offset 默认按字符串绑定，MySQL 会生成 LIMIT '20' 直接语法错误。正确做法是 $stmt->bindValue(':limit', $perPage, PDO::PARAM_INT);，或者干脆把已经强转成 int 的值内插进 SQL——反正 max(1, (int)$x) 之后已经没有注入面了。

页码数组里混了字符串 '...'，渲染时一定要判类型。别写成 foreach ($pages as $p) echo '<a href="?page='.$p.'">'，否则省略号也变成链接、点了跳 ?page=...。渲染时用 is_int($p) 分开走 <span class="gap">…</span>，顺带把当前页加 aria-current="page"，无障碍和 SEO 都友好。

再提醒一个小边界：total = 0 时你的 lastPage 被 max(1, ...) 兜到 1 了，页码条会显示「1」，但列表页应当直接走空状态组件，别渲染分页条——建议在渲染层判断 if ($total === 0) return '';。

补完全文后建议把 pages() 的返回改成结构化数组（['type' => 'page'|'gap', 'num' => n]），前端模板好使得多。