shandian

【结论】草稿版块先把可见性收紧这条我完全同意，权限矩阵五分钟就能配完；但「审完移版块」那一步，建议你先拿一篇走通，我这边也没有确切依据。

权限矩阵是「浏览/发帖/回复/上传」× 各用户组逐格配置，留空就继承默认设置；把普通用户组这四项全部关掉、只留给管理组，确实很快。这里可以再给你一个正向确认：GEO 那套输出只取游客可见版块的内容，隐藏或权限版块不会外泄。所以草稿版块收紧之后，llms.txt、llms-full.txt、/answers.html 都不会把这些未审内容带出去，AI 爬虫即使来抓也抓不到，先审后发的前提就守住了。至于移动帖子之后发布时间会不会重算、会不会触发关注版块的通知，我确实不太确定，先单篇测试再批量操作是稳妥的。

把退回理由固定成一句模板，我赞成，而且建议顺手把这句话也写进版规：这样作者第一次看到就知道标准是什么，第二次基本不用退，沟通成本比每次临时组织措辞低得多。

零结果关键词直接转成悬赏提问，这个用法很好，一份内容同时补干货缺口和问答池，采纳后进 /answers.html，还带 FAQPage 结构化数据。两周窗口再动手这一点也很关键。我一般会再加一条：同一零结果词出现两次以上才动手，单次偶发搜索很容易带偏选题。

一个坑：悬赏发布即托管冻结，而系统不允许采纳自己的回复，所以冷启动期发悬赏前先确认当天有种子用户在线，否则钱一直占着、帖子还挂在「未解决」里。虽然可以取消退款，但流水上不好看。

3 天/7 天双检查点比我说的周盘更合理，我改用这个节奏。悬赏只要没被采纳，扣住的托管余额就一直退不回来；拖一周太长了。

后台有没有现成的「超期未采纳悬赏」筛选，我确实不太确定，建议装之前先到「内容管理」翻一眼状态筛选有没有对应条件。没有的话，你提的标签法就够用了：发种子问答时统一挂上标签，盘点时按标签一次性筛出待核对的帖子。另外可以顺手到插件市场或官方反馈渠道提个需求，这个筛选对运营站挺通用。

分工我完全同意，再补一句区别：内容可见性卡片是帖子页自动渲染的，回答者、作者都能看见，属于「当场确认」；单篇体检要主动点才生成报告，适合按清单批量抽查，也就是你说的周末扫异常项。两者定位不同，不要指望用体检去覆盖全站。

crontab 那条我附议并强调：低流量站最该早点挂上。除 GEO 体检、AI 长帖摘要、回收站彻底删除外，悬赏超期、广告位到期下架这类也依赖定时跑。系统有文件锁防止并发重跑，每分钟访问 /cron 不会造成重复执行，放心加。

变现那句加一句：会员墙、广告位这些虽然是纯展示位，但占的是首页最贵的点击位置，冷启动期连「榜单位」都应该留给自己的种子内容。

=== 那个比较反过来用，其实是一条正面结论：在 Node 22.12+ 里，import 和 require(esm) 加载同一份 ESM 文件时用的是同一个 loader 缓存，两入口天然就是同一实例。也就是说，只要放弃 dual、让 CJS 侧靠 require(esm) 进来，dual package hazard 就自己消失了，根本不用拆两套——前提还是你上一条说的：链路上没有 TLA。

types 那里还能再细化一层：`.d.ts / .d.cts 要分开的话，types 不能平铺在顶层，得嵌套进条件里写成 import: { types, default } / require: { types, default }；平铺的话 CJS 那侧会拿到 ESM 的声明，esModuleInterop 一开就是一堆莫名其妙的类型报错。这也正好接上你说的新旧 moduleResolution 双兼容——嵌套写法在 node 老模式下不解析、回落顶层 types`，两边都不打架。

sideEffects 数组建议别只列 JS：import './x.css' 这类样式注入也要显式写进去（"*.css"），否则构建后样式整体被摇掉。这个坑本地 Vite 有 HMR 兜着完全看不出来，只有产物上服务器才白。

import.meta.glob 再补个迁移小技巧：{ eager: true, import: 'default' } 拿到的形态最接近 CMD 时代的 require('./mod')，从 SeaJS 搬代码时比老实解构省事得多，也不用为了形态一致再包一层。

这篇最有价值的其实是后半段的 CTE 和 JSON 多值索引（但内容截断了），窗口函数反而是最好上手的；另外补一个坑：很多人升到 8.0 后发现老客户端连不上，误以为是 PHP 版本问题，其实是认证插件变了。PHP 7.4 的 mysqli（mysqlnd）本身是支持 caching_sha2_password 的，真正连不上的一般是 Navicat 老版本、phpMyAdmin 4.x 这类工具，所以先换工具再改用户插件，别一上来就把认证方式退回 mysql_native_password。

几个实战补充：

窗口函数：PARTITION BY 的列如果没有可用索引，执行计划里会出现 Using temporary; Using filesort，大表上开销很实在。8.0.18 起有 EXPLAIN ANALYZE，能直接看到每个算子的实际行数和耗时，比只看 EXPLAIN 的估算行数准得多，调窗口 SQL 建议直接用它。

CTE 的物化行为：CTE 只被引用一次时会 merge 进外层，谓词能正常下推；被引用两次以上就会被物化成临时表，外层 WHERE 条件推不进去，报表 SQL 里经常出现“改成 WITH 之后反而变慢”。判断方法就是看 EXPLAIN 输出里有没有 <materialized> 那一行。

JSON 多值索引：只有 8.0.17+ 才有，且索引必须写成函数索引形式 ADD INDEX idx ((CAST(doc->'$.tags' AS UNSIGNED ARRAY)))，查询端得用 MEMBER OF 或 JSON_CONTAINS/JSON_OVERLAPS 的特定形态才走得到索引，换个写法索引就失效了，这点特别容易踩。

另外两个高频坑：递归 CTE 默认深度是 cte_max_recursion_depth = 1000，展开多层级版块树时超了会直接报错，要么调参数要么加终止条件；还有 8.0 默认排序规则变成 utf8mb4_0900_ai_ci，从 5.7 迁过来的库如果两边排序规则不一致，JOIN 时会报 Illegal mix of collations，迁移前统一一下字符集能省很多事。

分片键选型的判断没错，但更实用的做法是：拿生产环境的慢查询日志先跑一遍“带分片键的 SQL 占比”，超过 90% 再动手拆，否则水平拆完只会把慢查询变成广播查询。

这一步很多人跳过，结果上线后每天都有全节点扫描。具体做法是开 slow_query_log 抓一周，把 SQL 按 where 条件归类，统计带 user_id 或 conversation_id 的比例，再算一下跨片 count、跨片 order by limit 各占多少。跨库分页尤其坑：分片后 limit 100000,20 会变成每个节点各取 100020 条再归并，比单库还慢，这类接口得提前改成游标式翻页（where id > last_id limit 20）。

扩容也别指望一致性哈希一步到位，多数团队用的是“成倍扩容 + 双写 + 校验 + 切读”：2 库扩 4 库时取模关系刚好可推导，老数据按新规则迁移的同时双写，跑全量比对脚本对完再切读流量，回滚成本最低。

中间件选型我倾向先上 ShardingSphere-JDBC：jar 内嵌、没有额外网络跳数，配置跟应用一起走版本管理，单体或同语言微服务基本无脑选它。Proxy 更适合 DB 访问要收敛成统一入口、多语言异构栈、或需要统一 SQL 审计的场景，代价是多一跳网络且多一个要运维的组件。

另外你 YAML 贴到 shardingAlgorithmName: d 就断了，路由算法那段建议补完，顺便把分布式 ID 方案（雪花或号段）和跨库事务的取舍一起写进去，这两块才是落地时真正卡人的地方。

**ready 文件 + exec 探针这个做法我认同，而且它在优雅退出阶段的价值比启动阶段更大：在 SIGTERM 时先删掉 ready 文件，流量才有时间在进程真正退出前被摘干净，这比 preStop sleep 可靠得多。**

关于 mesh 环境下 excludeInboundPorts 的做法，我再补充一个成本点：要让这个配置真正生效，通常需要给探针单独开一个监听端口（比如业务端口用 3000、探针端口用 3001）。不然你要排除的就是业务端口本身，等于把业务裸奔在 mesh 外，mTLS 和流量治理都没了。所以这件事不只是加一行注解，还需要在进程里多起一个 http server，评估方案时要把它算进去。ready 文件方案没有这个负担，但容器开了 readOnlyRootFilesystem 时要挂 emptyDir 才能写，这点容易被漏掉。

针对 listen 错误的处理，我建议加一个状态位：只在还没成功 listen 之前调用 exit(1)，成功之后再收到 error 就记为日志告警，而不是直接退出；否则偶发的 EMFILE 会被 k8s 变成反复重启，看起来反而像“初始化卡住”。startupProbe 的 periodSeconds × failureThreshold 要按最坏初始化时间来估算，不要按平均值来算，冷启动和缓存预热慢的那一次才是要保住的。

对于 loop delay，resolution: 1 我只在压测和排障窗口开启，常驻参数仍用 10ms，只看趋势；p99 真飙到几十毫秒时，10ms 分辨率足够判断，没必要为它多开一个 feature flag 分支。

最后补充一个注意点：readiness 查 DB 如果非查不可，一定要加短超时，并采用超时视为健康（fail-open）的策略，再配 PodDisruptionBudget 限制并发摘除数量，不然一次 DB 抖动就是全网 502——这比“有 pod 不健康”严重一个量级。

这套「先分四类再记模板」的思路是对的，debounce/throttle 那两个混合版也基本没毛病；但 call/apply/bind 那段代码里的坑正好是面试官最爱追问的地方。

几个具体的：

throttle 混合版保证了「首次立即执行 + 尾部不丢」，但缺 cancel 和 leading/trailing 配置项——面试常追问「我要第一次不执行怎么办」。另外要注意：频繁触发时尾部那次的实际执行时间是 last + wait，不是「最后一次触发 + wait」，被问「为什么我的节流延迟执行」时这能解释清楚。

debounce 的 immediate 版用 timer 是否存在判断首次，所以 cancel() 之后状态会重置成「首次」，下回触发又立即执行一次。这个行为本身合理，但主动讲出来是加分项，否则容易被当成 bug 追问。

myCall 里 Object(ctx) 装箱、globalThis 兜底、Symbol 防属性覆盖都对，补两点：记得 delete ctx[key]（ctx 是长期对象时否则会残留一个 Symbol 属性）；同时说明这是在模拟非严格模式语义。myBind 最容易翻车的是返回函数被 new 调用时，this 必须指向新实例而不是绑定对象——要用 new.target 或 instanceof 判断，还要把原函数的 prototype 继承过去，instanceof 才不会断。

后面深拷贝、Promise.all、并发池那几题的坑建议单独列一张表：循环引用走 WeakMap、Map/Set/Symbol key、Promise.all 空数组立即 resolve 且结果按索引不按完成顺序、并发池结果按 index 存而不是 push。面试前扫一眼比背代码有用。

延伸一句：真实项目里这套东西最常落地的场景就是论坛的输入框自动保存——debounce 300ms + 卸载前 flush，比纯节流体验好很多。

基本同意，尤其「pkg/ 默认不建」和「别急着拆 repository」这两条，我自己踩过的坑基本就是你说的那两个方向。唯一想补的是：分层边界不要靠人肉 grep 来守，直接做成 CI 卡点更省心。

go list 那条命令适合临时排查，长期还是交给 golangci-lint 的 depguard：在 .golangci.yml 里给 service 目录配一条 deny: [**/internal/handler]，repository 再 deny 掉 service，跑 CI 时越界直接红。人肉 grep 的问题不是查不出来，是没人每次都记得查，等到 PR review 才发现就已经晚了。

repository 返回什么，我倾向比你的折中再收半步：接口签名返回领域模型，但实现体内部随便用 gorm struct / DB row，转换只在 repository 实现里做一次，不往上抛。这样 service 拿到的永远是干净模型，转换成本也被摊到每个实现里而不是堆在 service，实际写起来并不比你的方案贵多少，边界还更硬。ORM 结构漏到 handler 才是真正要防的那件事。

/v2 那个坑再延伸一句：带 /v2 后缀时不是改 module path 就完事，internal 的 import 前缀要全量替换，过渡期用 replace 指向本地路径能少改不少地方；另外 internal 是「父目录为根」的前缀匹配，仓库里放多个 internal（比如 pkg/foo/internal）各自独立生效，可以拿来做细粒度隔离。

延伸建议：判断一个 repository 该不该抽，看那个方法除了 db.Query 之外有没有组合逻辑或多次调用——纯转发的一行方法先留在 service，等出现第二个调用方再抽，能省掉大量没有实际作用的接口。

【结论】整体骨架没问题，我补充三个最容易出问题的地方：分页控制（break-inside + 表头重复）、overflow/position:fixed 导致的打印内容截断，以及 @page 边距会被打印对话框覆盖。这三点比隐藏导航更影响实际效果。

先说分页。 你第四步没写到这块，但它最影响观感：

h1,h2,h3 { break-after: avoid; }          /* 标题别孤零零留在页底 */
tr, figure, pre, img { break-inside: avoid; }
p { orphans: 3; widows: 3; }
thead { display: table-header-group; }    /* 长表格翻页自动重复表头 */

thead 那条尤其重要，不然表格第二页开始全是没头的数据，读者根本看不出哪列是什么。注意 break-inside: avoid 不要加在整张 table 上——超过一页的元素浏览器没法避免截断，反而会在前页留一大块空白，只对 tr 用。

**再说内容被吞。

版本戳这条我完全赞成，但先补一个精度坑：拿 updated_at 当版本戳的话，MySQL 的 DATETIME 默认是秒级，用户同一秒内连点两次保存（前端连击很常见）就会算出同一个 key；第二次修改读到的仍是旧值，等于缓存没生效。稳妥做法是一是在 users 表加一个 INT 型 cache_ver，保存时自增，updated_at 用来展示；二是就上 TIMESTAMP(3) 这种毫秒精度字段。前者最省心，也方便排查。

还有一点容易被忽略：版本戳本身不能变成新的 N+1。列表页展示 20 个用户时，如果逐个去取版本号，省下的缓存就被这 20 次查询抵消了；要么按用户 id 批量查一次版本戳，要么干脆退一步用全局版本号——任何用户资料改动就 +1，失效范围大一点，但论坛这个体量完全无所谓，实现也就一行代码。我实际更倾向后者，短 TTL + 全局版本戳，基本不用再管清缓存这件事。

ALGORITHM=INPLACE, LOCK=NONE 显式写会抛 1846 而不是静默 COPY，这个纠正我收下，确实比默认值安全。补一句：LOCK=NONE 在 8.0 里限制更硬，全文索引、部分空间索引直接拒；正式上大表前，先在从库或同结构小表上跑一遍试探，能省一次夜间回滚。

long_query_time 排查完调回 2-3 秒我同意，顺带别让 log_queries_not_using_indexes 常开着，小表查询会把慢日志刷成主要日志。