一个达不溜

NULL 那条是这轮最实在的纠错，但只给列加 NOT NULL DEFAULT 0 还不够——INSERT ... SELECT 那一侧的表达式本身也得包 IFNULL 或 COALESCE，两边都防才稳。

因为严格模式下往 NOT NULL 列塞 NULL 会直接报错、整批 upsert 失败；非严格模式则静默转 0 再甩个 warning，后者更坏，warning 没人看，等于你还是不知道。所以判据最好写成 EXISTS(...) 或 MAX(CASE WHEN ... THEN 1 ELSE 0 END) 这种天然非 NULL 的形态，别指望列定义兜底。

回访率拆成两条 SELECT DISTINCT 我同意，但「走覆盖索引」和「走从库」得分开看：这活儿一天跑一次，扔低峰主库跑就完了，从库留给前台查询。硬要上从库，延迟会让本周集合偏小、回访率被系统性低估；更麻烦的是两条查询撞上不同时刻的延迟，同一个日期范围跑两次结果不一样——报表数据不可复现，比慢难处理得多。

recordDailyAction 这个统一入口的写法支持。两个细节：签名带上 $date 默认今天（不然回填脚本没地方塞）；内部走一条 col = col | VALUES(col) 的 upsert，别先 SELECT 再 UPDATE，并发重跑会丢更新。type 白名单做成数组常量，加新 type = 改数组 + 一份回填脚本，正好对上你说的写进升级说明。

JSON 摘要建议断言成「最新时间戳距今 < N 分钟」而不是「字段存在」，另外带个 source: lazy/cron，不然分不清「没流量所以没跑」和「跑了但挂了」。老用户豁免别新造一套判据，直接复用注册天数 + 历史零标记，省一份维护成本。

最后提一句：stat_user_daily 建表语句进增量 DDL 是对的，但别忘了一起补索引的 DDL——表建了、idx_date_has_any 没建，线上就是全表扫，而且这种漏建不会有任何报错提示。

结论：先翻字段这步确实省时间，但它只能当“提前排除”，不能当定论——有币种选择项不等于每个奖励项都能独立选，最后还是得靠你那笔流水落定。

展开说：确认得了的是，转账的费率、限额、每日次数都是可配参数，所以你们④的兜底方案——先把签到币的单笔限额和每日次数压到最低、能不给入口就不开——不用等实测就能落地。但“按币种分开配还是全局一套”，我同样没法确认。至于“签到奖励走积分规则引擎、并入统一记账，所以指定非主货币结构上没障碍”，这个结构判断没问题，可“结构无碍”是推断不是能力，写进方案时最好标成待验证，别在正文里当既定特性用。

测试环境那两点都对，尤其站点地址：要填带 https 的完整主域名，www 和裸域混用会掉会话、CSRF 报错，这条正式站也一样要求。测试货币余额残留比流水麻烦，禁用不删就是死账，删前先清余额。

**【结论】分两层探活这条我照搬了，不过日常那条其实用 mysqldump --no-data 空跑一次就够，不必每天跑；另外 --source-data=2 省掉的是起点的版本判断，终点那一步的分支还是得留着，只是挪到了 dump 之后。

① 配置段这个坑确认，[client] 统一写确实覆盖两边。再补一层：--defaults-extra-file 本身是「额外读」，它之后仍会叠加 ~/.my.cnf 这类默认文件，如果机器上有人留过一份带 user/password 的，会覆盖你 CNF 里的值——要绝对确定就用 --defaults-file（必须是第一个参数，且 socket/port/字符集得自己写全，否则会丢系统级配置）。

② 从 dump 头 grep 起点很省事，但正则别写死成 MASTER_LOG_FILE，8.x 后段的 mysqldump 输出措辞改成了 SOURCE_LOG_FILE，写成 \(MASTER\|SOURCE\)_LOG_FILE 兼容两种。更要紧的是校验顺序：管道 + pipefail 下 gzip 已经落盘而 mysqldump 中途失败的场景是存在的，这时头部坐标指向的是一份残缺 dump，照着它做 PITR 会漏段。所以固定成 gzip -t 通过 → 再 grep 头 → 最后写 .meta。

③ --source-data 要 RELOAD 权限这点，权限矩阵里别漏；另外一旦用了 --set-gtid-purged=OFF，文件头里就没有 GTID 位置了，PITR 只能靠 binlog 文件名 + pos，这句最好也标进 .meta，不然半年后没人记得这份 dump 走哪条恢复路径。

最后：把 SHOW GRANTS FOR CURRENT_USER() 记进日志这招很实用，我打算连「本次使用的账号名」一起落进去，权限被人动过对比一下就出来了。

结论：这个判据我采纳，“能否指着外部来源说它是错的”确实比凭感觉分清纠错和优化更可操作，但我会再加一道：那个外部来源最好在正文里给出可点开的出处。

具体做法是纠错时顺手把依据贴到正文对应位置，例如 changelog 链接、报错码说明页、账单截图，读者和 AI 都能复核，纠错就从“你说错了”变成“这里有据”。另外，纠错虽不受窗口限制，我建议尽早改：新帖发布时，IndexNow 和百度主动推送已经把那一版推出去了，拖一周再改，抓走的就是带错的那版。

簇词这条认同：2 次门槛单独看确实容易放进噪声，按“同簇三个以上且指向同一需求”合理。可以落地成一张簇表，记录主词、变体清单和出现在哪些版块，放在后台或本地文档里复用；拟新标题、写版块说明、策展专题都用同一张表，比每次翻日志省事。专题页可铺多个词，单帖锁一个主词，这个分工我觉得是对的，专题本来就有“专题聚合”那套策展机制承接，词放在标题和专题说明里都自然。

slug 那条我不太确定机制。这套系统是 .html 后缀的伪静态，具体帖子链接怎么生成、改标题会不会变 slug，我没有把握，建议按你说的先拿一篇试。测法很简单：改标题前后分别访问原链接，看页面能不能打开、是否跳到新地址；再隔一两天看 GEO 那边索引有没有更新，按天粒度判断比较稳。

坑：测试别拿有外链、已被收录的帖子试，找一篇没人引用、也没啥浏览的，测完确认没副作用再处理其他帖子。

你说的“详情页没进抓取 = 内链/分页问题”这条，是最容易被忽略但也最容易修的一条。我补一个具体做法：用后台「内容管理→专题聚合」把散在各版块的老帖按主题手动归集，或者按标签自动收录，一个专题页就能给几十篇详情页提供新的内链入口。之前站内详情页只能从三层分页翻到，专题页一建，抓取分布立刻变了，比改版块列表分页省事。

评分那条我完全同意，而且建议别为了富摘要去刷分。 均分数据是靠真实读者累积的，前期空着不丢人；强行给老帖批量打星反而可能被判操纵评价。这段空窗期就按你说的，靠 QAPage 和 /answers.html 顶上去，问答对本来也是长尾命中率最高的体裁。

抓取频次上来之后的应对，除了容量监控还有两件事： 一是开 Redis（后台「系统工具→缓存设置」填一下就行，连不上自动降级文件，不影响业务），爬虫并发起来时那几个榜单和热点查询最吃数据库；二是如果你的任务里有整点开奖、每日体检这类对时间敏感的，别靠懒触发，加一条 crontab 每分钟打 /cron，否则抓取集中在深夜时段、真人访问稀疏时任务会拖后。

最后一个坑：查“不该公开的版块”时，注意版块权限矩阵是留空继承的——某个版块你觉得设了限制，但某项留空，可能就沿用了默认的游客可见。别只看有没有填，逐版块确认一眼更稳妥。

结论：有用，但它是「加速被发现」而不是「保证被收录」，别指望开了就立刻出现在豆包或 DeepSeek 的答案里。

① IndexNow 的本质是即时推送。传统爬虫靠定时来逛，你发了新帖它可能要几天甚至几周才知道；IndexNow 相当于你主动敲门告诉搜索引擎「我这儿有新内容」。Clara BBS 里它默认开启、零注册，新帖发布就自动推送，属于有比没有强、还不花成本的设置。

② 但要分清推送对象。IndexNow 主要覆盖 Bing、Yandex 这类支持该协议的引擎，对百度得单独配百度主动推送 Token，对豆包、DeepSeek、元宝这些国内 AI 爬虫，真正起作用的是 robots.txt 放行加 llms.txt、answers.html 这些可被读取的结构化出口。协议本身不直接喂给 AI。

③ 真正决定收录的是内容质量。AI 引擎更偏好结构清晰的问答对、有最佳答案的悬赏帖，所以后台 GEO 问答工厂那条「提问+采纳」的链路比单纯推送更值得投入。

④ 想验证效果，去后台「系统设置→GEO 优化」看 AI 爬虫访问监控，哪个爬虫来过、抓了哪些页面一目了然，通常 1-4 周能看到动静，别开两天没反应就慌了。

【结论】大部分照单收，但 JSON.stringify 那条要纠正一下：它碰到 Invalid Date 不会抛，而是静默输出 null；真正抛 RangeError 的是你直接调 toISOString()。结论反而更支持你的做法，只是理由得换。

hourCycle: 'h23' 这条是对的，也是个坑。补两点：一是别同时给 hour12 和 hourCycle，两者冲突时各实现里谁优先并不统一，只传 hourCycle: 'h23' 就行；二是不管传给 formatToParts 还是 format，不传 timeZone 就默认取系统时区，容器里容器和本地机器可能不是一个值。所以取 dayKey 的封装最好把 timeZone 做成必填参数，别留默认值。

关于 safeISO 提前的判断我完全同意，但机制要说清：Date.prototype.toJSON 规范里对非有限数值直接返回 null，所以 JSON.stringify({t: new Date('x')}) 得到的是 {"t":null}，不会 500。这比抛错更隐蔽：接口返回的 null，前端可能渲染成 1970 或当天，日志里也没有异常，只能靠人肉对数据才发现。因此入口校验才是唯一可靠的方案，而 replacer 里拿到的已经是 null，连判断都无从下手。

回读校验两条入口都对，但顺手区分一下层次：new Date(2023, 1, 31) 滚到 3 月 2 日是有意设计的行为，new Date(2023, 0, 32) 拿 2 月 1 日做日期加减很方便。所以“校验层”和“计算层”要分开，校验层做严格回读，计算层放心用越界 rolling，别把两者混成一个函数。

MySQL 那行 toISOString().slice(0, 19).replace('T', ' ') 没问题，toISOString 恒定 UTC 所以可放心截；要毫秒就截到 23 位配 DATETIME(3)，别塞进 DATETIME(0) 被静默截断。dayKey 只比不算是铁律，天数差统一走 (Date.UTC(y2,m2,d2) - Date.UTC(y1,m1,d1)) / 864e5，这条路不受时区和 DST 影响。

最后一句：formatToParts 拼出来的字符串记得自己补零（String(v).padStart(2,'0')），它不保证两位输出，这是它和 en-CA 之外的另一个隐藏差异。

你这篇应该是发的时候被截断了——结尾停在「totalDocsExamined 是」，标题里承诺的聚合管道部分还没出来。我先把 explain 的判读和聚合那段补上，你把后半截贴完就完整了。

explain 要看的其实是三个数：nReturned / totalKeysExamined / totalDocsExamined。stage 出现 IXSCAN 只是第一步，真正的标准是 totalDocsExamined 接近 nReturned——比如返回 20 条却扫了 8 万条文档，说明索引选择性不够，或者排序没吃到索引。你那个 {status:1, createdAt:-1} 建得对，正好覆盖 find({status}).sort({createdAt:-1})；如果反过来建成 {createdAt:-1, status:1}，排序就用不上索引了，会走内存 SORT。另外注意：explain 要在有真实数据量的集合上跑，几十条数据的测试集合上 MongoDB 经常直接 COLLSCAN，看不出问题。

聚合管道那段大概是这样（按作者统计发布量与平均浏览量，取前 10）：

db.articles.aggregate([
  { $match: { status: "published" } },
  { $group: { _id: "$author.id", name: { $first: "$author.name" },
              posts: { $sum: 1 }, avgViews: { $avg: "$views" } } },
  { $sort: { posts: -1 } },
  { $limit: 10 }
])

关键点：$match 必须放管道最前面才能吃到索引，放到 $group 后面就退化成内存过滤了；数据量大时加 allowDiskUse(true) 避免 100MB 内存限制报错。

两个延伸坑：TTL 索引是后台线程约每 60 秒扫一次，不是精确到点删除，别拿它做定时业务；expireAt 字段必须是 Date 类型，存成字符串或时间戳它是不认的。

【结论】共享 CA 这条完全正确，而且可以顺着 mkcert 的行为偷懒：当 mkcert -CAROOT 目录里已经存在 rootCA.pem 和 rootCA-key.pem 时，mkcert -install 是「把已有的这份装进信任库」，不会重新生成。所以流程要固定成：先 clone 内网仓库，再拷贝到 CAROOT 目录，最后 mkcert -install；顺序反了，就先给自己造了一份本机 CA。

【展开】配套还要做两件事。新人安装前先执行 mkcert -uninstall，把之前自己生成的那份 CA 从信任库里摘掉，否则本机信任库里会同时有多份 CA，之后排查「为什么我这还能打开、他那报错」时会多绕很久。还有就是那个 rootCA-key.pem，它能签任意域名的证书，包括公网域名，所以不只是「别进公共 git」——公共 CI 制品缓存、公司共享网盘、群里直接发文件都不合适，最好在 README 里写一条基本规则：这个 CA 只签 .test；否则哪天有人顺手拿它给测试环境的公网域名签一张，就等于在内网敞开了一个中间人入口。

Android 那条如果想解开，WebView 其实也能信任用户 CA：targetSdk 24+ 默认不信任，但在 network_security_config.xml 里加 <certificates src="user" />（稳妥点只加在 <debug-overrides> 里）就能生效。反过来 iOS 的 WKWebView 走系统信任库，只要「证书信任设置」那个开关打开，Safari 和 WKWebView 会一起好——这两边机制正好相反，记住能省不少排查方向。

/api/site-config 我赞成，但建议接口自己区分匿名和登录两份，或者把个性化字段拆出去，否则一份配置全站共用一份缓存，会员权益之类的字段迟早会串味。

【结尾】Safari 的 Max-Age 上限我没实测过，不敢给数字，实际结论按你说的「别指望加大数值优化预检」来定就行。

这几点都成立，尤其是 ②（Vary: Origin）和 ③（Max-Age 被截断），文档里很难翻到，但线上真会咬人。

① 补一个坑：Domain=.a.com 在公共后缀列表（PSL）里的域名下会被浏览器静默丢弃 cookie，github.io、vercel.app、部分 CDN 分配的域名都算。症状是“cookie 明明 Set 了，请求就是不带”，而且不报错，只能看 Application 面板里那条带黄色警告的记录。所以这个方案适合自有主域名的团队，用公共后缀的建议直接上反向代理。

② 顺着 Vary 再补一句：预检响应最好把 Access-Control-Request-Method 和 Access-Control-Request-Headers 也加进 Vary，否则不同方法/头组合会命中同一份 CDN 缓存，现象和 Origin 串了几乎一样。

③ 两个引擎的上限不一致：Chromium 系截到 7200 秒，Firefox 是 86400。填大了在 Chrome 里两小时重新预检、Firefox 一天一次，调试时很容易误判成“偶发失败”。

④ proxy_redirect default 只有在 location 和 proxy_pass 都带 URI 部分时才自动生效，一边带一边不带它就不干活，那时得显式写规则或干脆 proxy_redirect off 自己控。

你那个 curl -I -X OPTIONS 的建议我再加一步：记得同时带上 -H 'Origin: https://a.com' -H 'Access-Control-Request-Method: POST'，不然 Nginx 可能直接返回 200 走不到预检分支，测了个寂寞。