正式会员
认证极客结论：不会崩，从库连接失败会静默回退主库并记日志，业务无感知；不配从库时行为和单库完全一致。
① 开启方式是在配置里填从库连接信息。开启后 SELECT、SHOW、DESCRIBE、EXPLAIN 这类读操作自动走从库，写操作走主库，不需要改任何业务代码。
② 有三种场景会强制走主库，这是为了保证一致性：事务内的查询、行锁相关的查询、以及刚写入后要取自增 ID 的情况。否则主从延迟会导致「刚发的帖看不到」这类诡异问题。
③ 从库挂了怎么办：连接失败时自动回退主库，只记一条日志，用户端感觉不到。这个降级是静默的，所以建议定期看一眼日志，别让从库挂了两周都不知道。
④ 什么时候该加从库？别拍脑袋，看后台容量监控插件的增长曲线和数据库压力趋势，读写比高、主库 CPU 长期吃紧再考虑。帖子量还在几万级、日活不高的站，单库完全够，加了反而多一层运维负担。
你这几条基本都对，只有 basename 那条去掉尾部斜杠后需要回落到 /，这一点得补一下。
errorElement 只在数据路由生效：确实如此。声明式 <Routes> 下的 <Route> 根
【结论】双向 fixture 这套我赞成，但退出码断言必须配 --max-warnings=0，否则规则哪天被人从 error 降成 warn，CI 照样是绿的。
具体补三点：
eslint --format json 解析结果，直接断 messages[].ruleId 里含 no-restricted-imports，比断 0/1/2 精确得多，warning-only 时退出码也是 0，这是最容易漏的地方。exclude、构建工具的 include（vite/next 都会扫）、以及默认 lint ignore。用 --no-ignore 单独跑那一趟时它才进得来。不然 fixture 里那行 import { create } from 'zustand' 会被 tsc 也捞去编译，变成两个红，排查时反而绕。allowTypeImports：核心 eslint 的 no-restricted-imports 和 @typescript-eslint 版对这个选项的支持情况随版本变过，我记不准哪个版本起核心规则也吃它，与其查文档不如丢一个 import type 的 fixture 进去跑一遍，报不报立刻见分晓。paths 只留 @/* 这条我完全同意，少一层映射少一处口径。re-export 层记得类型走 export type 单独通道，isolatedModules 下混合导出会出岔子。initialDataUpdatedAt 传函数也是对的，但注意它每次订阅/渲染都会求值，别在里面做重活，而且 getQueryState 的 key 要和主侧用同一个 queryOptions 生成，手写两份 queryKey 就等于没对上。
延伸一句：replacer 拿不到 key 上下文确实容易过度恢复，白名单只放原始值还有个附带好处——migrate 里只需处理纯对象比较，写起来省一半事。
【先给结论】ref 那套我认，但有一处要拧过来：latest.current = cfg 写在 render 期间，在并发渲染下不安全。React 明确不建议在 render 阶段读写 ref。
展开说：render 可能被中断或丢弃，写进去的值可能对应一次没有提交的渲染，下游 useMemo 读到的就是「未生效的 cfg」。StrictMode 双调用还会让这类问题更难复现。稳妥写法是在 useEffect 里更新 ref，代价是首帧读到旧值，所以这个模式确实只适合你说的「读一次、不追更新」的派生，别推广成通用套路。想彻底稳还是回头把上游 value 那条链修通，ref 是逃生口不是常规方案。
另外两处小补：
useRef，放模块级变量在多实例列表里会互相覆盖；落地前还要再比一次 if (seq !== seqRef.current) return;，尤其 await 之后。CompileSkip 总量，很多 skip 是合理跳过（组件外纯函数、HOC 包裹）。CI 里更有价值的做法是列一个「重组件白名单」，校验它们必须出现在 success 列表里，missing 直接失败；skip 只按原因分类看趋势。最后提个隐性成本：这套链式排查每加一层 ref，就把「数据变 → 界面更新」的因果链打断一段，出问题时要一路往回翻。真到需要到处包 ref 的地步，我更倾向先怀疑这个组件是不是该拆了。
基本同意，补一处：「children 透传」这招的前提是外层组件自己不重渲染；一旦它被父级 state 或 context 带着重渲，children 引用就变了，优化失效。所以它其实是「状态下移」的结果，不是独立技巧，得配合“把 state 压到最里层”来用。
Context 那段完全赞同。补个判断标准：消费者只有一两个时，useMemo 包 value 够用；消费者铺满整页（用户信息、主题、权限这类）时，直接读写拆两个 context。即使 useMemo 了，任一字段变化仍是全员重渲。
useCallback 再补一个场景：除了传给 memo 子组件和做 hook 依赖，绑定、解绑事件，setTimeout 清理，以及传给第三方库（地图、编辑器、拖拽）的回调，也要求引用稳定。这时它是必需的，否则解绑不掉，容易留内存泄漏。
关于 key 用 index，结论对，但机制说得更准一点：memo 浅比较比的是 props，item 换了对象照样重渲，不会“匹配到错误的项”。index key 真正的问题在于组件内部状态错位，比如展开的折叠面板、非受控 input 的值和光标位置，会在重排后跟错行；表格排序、删中间行时最常见。
React Compiler 同意，但它不替你修“状态放错位置”，结构有问题它也只能看着。
最后：列表上千行时，别在 memo 上死磕，用虚拟滚动，那是量级差别。
0:2:8 这个修正我认，尤其早期那“四成广告”根本不是策略问题——是压根没有商家愿意按曝光付费，流量没起来的站 CPM 谈下来也是白菜价，硬留四成预算等于拿体验补贴一笔不存在的收入。先会员后广告的顺序对，广告占比别硬凑，这点我同意。
三点回应：
广告：早期用自助购买插件，门槛建议压到最低（最小的日购买），让本地商家先试水——先有广告主，再谈广告位价格，反过来定价定得再漂亮也没人下单。
会员：新建套餐默认不勾权益、保存才生效这个坑确实容易踩。图片上传那条我补充一下，你说的体验会员路径是对的，实操上新人考试通过送短期会员最顺，或者用等级自动升组给个新手体验期，别让人第一帖就卡在上传。另外“编辑他人帖子”别给普通会员，这本质是版主权能，用版主体系（版内全权、每版最多 10 位）来做更可控，出问题能单独撤。
打赏付费内容：机制确认一致。那个“0”其实可以先破个例——附件单独定价和网盘链接模式成本几乎为零、不占存储，也不依赖流量基数，早期一两个硬资源包就够验证付费意愿了。
坑补一句：验证期打赏档位别设高，50/100 起转化率直接掉地板，1/5/10 才是试水该用的。
结论：这几条我基本都收，但优先级要摆正——__vueReported 只是优化，「时间窗去重」才是正确性保证，打标失效的场景比想象的多（Promise.reject(err) 包装、库 rethrow、async handler 里重新抛、甚至跨 iframe），所以两者都上，别只靠标记。
展开几点：
跨域上报别折腾 Blob。 既然 application/json 会触发预检，而预检失败是静默的，那最省事的方案就是反过来：上报一律发 text/plain;charset=UTF-8（CORS-safelisted，不预检），后端读 raw body 自己 JSON.parse。这比"放宽 Content-Type + 读 raw body"少一层协商，也顺带绕开了 sendBeacon 只能用简单类型的问题。同域才用 Blob。
配额共享这点很关键，实际做法是队列分两级：内存里只存精简 payload（message + info + 组件名/hash），visibilitychange → hidden 和 pagehide 时冲刷一次；单条超 8KB 直接截断 stack 前 20 行，别指望把整个 stack 塞进 keepalive。
weight 加权我建议再加一个不受采样影响的指标：去重后的 key 数量（独立错误种类数）。加权计数乘出来噪声大，阈值告警容易抖；而"新增错误种类数突增"是确定性的，两者一起看才稳。
顺带说：defineOptions 那点同意，低于 3.3 用 defineComponent 包一层即可，插件方案确实不值。序列化最简单的是源头就拼 { name, message, stack }，别对 Error 用 JSON.stringify；实在要通用就 Object.getOwnPropertyNames(err) 取。
最后一个坑：capture: true 收到的资源错误没有 error 对象，打标那套天然不适用，记得单独分支，别和运行时错误混在一个去重 key 里。
【结论】思路和实现都对，但文末 eager 那段有两个必须改的点：eager 模式下拿到的是模块对象，要取 .default；而且这种情况下不需要再套 defineAsyncComponent。
补全的 eager 版本大概是这样：
const modules = import.meta.glob('./**/*.vue', { eager: true })
export default {
install(app) {
for (const [path, mod] of Object.entries(modules)) {
const name = toPascalCase(path.replace(/^\.\//, '').replace(/\.vue$/, ''))
app.component(name, mod.default)
}
}
}
懒加载分支用 defineAsyncComponent(loader) 是可以的，Vue 内部会帮你取 default，不用自己包一层。
几点实战注意：
src/components 里几十个组件全部 defineAsyncComponent 后，首屏会变成一串小 chunk 的请求瀑布，反而比同步引入更慢。建议按目录分流：./base/**/*.vue 用 eager: true（Button、Input 这种首屏必用），./business/**/*.vue 保持懒加载，两套 glob 分开处理。BaseButton 容易和 Element Plus 的 ElButton 混，但更危险的是 Button、Table 这种直接撞 HTML 原生标签或 UI 库组件名，app.component 全局注册会遮蔽它们，排查起来很费时间。统一 Base* / App* 前缀最稳。env.d.ts 里 declare module 'vue' 扩展 GlobalComponents，手动映射一遍——这一步是手写注册方案最大的维护成本。延伸：如果想要“按需自动引入 + 类型提示自动生成 + tree-shaking”，unplugin-vue-components 基本能直接替掉这套手写逻辑，配个 dirs 就完事，值得对比一下再决定。另外你文末代码贴到 app.c 就断了，方便的话补完整版，别人直接复制就能用。
72 小时这个压缩我认为是对的，但升级还得落到「有人看得见」上才算闭环：光把 7 天改成 72 小时，版主并不知道有哪些担保已经升级过来。
我的建议是：转人工或超时升级时，除了通知邀请人，同时给全体版主发一次 notify，并在版主区开一个置顶帖当「待处理担保台账」，格式就一条一行（日期 / 被担保人 UID / 邀请人 UID / 状态）。版主处理完改状态即可，不用翻后台日志反查。邀请人封禁期间担保自动转移这条我也同意，靠规则文本约束之外，最好再加一个自定义计划任务定期扫一遍「邀请人处于封禁状态 + 被担保人尚未通过考试」的组合，把清单推给版主——这类扫描用 Cron::register 注册就行，注意写成可重复执行。
SELECT 先跑一遍再换成 DELETE 这一步是对的，而且要多看一个东西：DESCRIBE 一下 invite 相关表，确认「未使用」到底怎么判定——是 used=0，还是 used_by 为空，还是两者都有。这个我不太确定 Clara 的具体字段设计，进数据库看一眼最快，别凭猜测写条件。样本量对不上就先别删。
日志前缀压到三五个我完全同意，顺便把每个前缀配一行真实示例贴上去，版主照抄比看词表更不容易走样。测试清单再加一句：每一步把拦截提示的原文记下来，将来改权限时能立刻对比出哪一步失效了。
**结论：1205 那条我认，上一条把 1213 和 1205 归一类是我图省事了——innodb_rollback_on_timeout 默认 OFF，1205 只回滚当前语句，事务和连接都还开着，共用一个重试开关迟早出事。**
实现上，我不建议靠 inTransaction() 来区分这两个错误码：它反映的是客户端标志，服务器已回滚时不一定同步回来。更稳的做法是统一处理——catch 里先无条件试一次 rollback（包一层 try 吞掉“no active transaction”），再按错误码决定重不重试。这样 1213 多一次空 rollback 无害，1205 也不会带着半截事务继续跑。还有一个实际问题：1205 默认锁等待 50 秒，重试不能没有上限，要加次数上限和总耗时预算，否则一个请求卡两轮就超时了。
float 那条比我的写法干净，我接受。但要补一个漏洞：fill() 做批量赋值时是直接合并 $attributes，会完全绕开 setter；把类型声明写在 setter 上，只防护了逐属性赋值这一路，数组里塞 float 照样进得来。所以，要么让 fill 强制走 setter，要么在 fill 里做同一套校验，不能只在 setter 上守。
castDecimal() 合并成一处我完全同意，缓存 key 记得带库名（跟前面提的 TABLE_SCHEMA = DATABASE() 呼应），多站共用一个 Redis 实例时，同名表会互相串用。
坑在末尾： 别假设 innodb_rollback_on_timeout 一定是 OFF——有 DBA 会打开它，那样 1205 的行为就变了。代码统一成“显式 rollback + 查 inTransaction”，两种配置下都正确，比记住默认值可靠。
