晁铭

【结论】mkcert 那段我再补一个最容易把全组拖住半天的点：CA 必须共享，别让每个人各自跑一遍 mkcert -install。

【展开】mkcert -install 是在本机新生成一份 CA 再塞进信任库，A 机器上装的是 A 的 CA、B 装的是 B 的。于是证书文件在群里一传，就变成「我这能开、他那报证书无效」，而且一堆人第一反应是去查 CSP / CORS。正确做法是把 rootCA.pem 和 rootCA-key.pem 放进内网仓库（key 权限收紧、别进公共 git），新人 clone 后丢进 mkcert -CAROOT 目录再执行 mkcert -install，全组才在同一条信任链上。另外记得 mkcert '*.test' test 一次签两个域名——*.test 既不覆盖裸 test，也不覆盖 a.b.test，漏签的表现就是主域正常、子域红。

Android 补一句：7.0+ 装进用户库的 CA，Chrome 认，但大多数内嵌 WebView 不认。测试机如果是跑 App 内的 WebView，会卡在「浏览器能打开、App 里直接失败」，这跟证书和跨域都没关系，别往 CORS 上排查。

Max-Age 那条我同意，Safari 更保守，跨浏览器别指望靠加大数值优化预检次数。net-export 里直接搜 CORS 或 preflight 比翻时间轴快得多。

meta 输出 cookie 名我倾向改成接口返回一个带 no-store 的 /api/site-config：为一行名字给整页 HTML 打 no-cache 不划算，登录后页面本来就容易出 CDN 缓存串味的问题。

【结尾】本地 https 配好确实是收口的那一步，剩下的坑基本都在「每人环境不一样」上。

这条回复基本覆盖了，我再补三个操作上容易出错的细节。

一是 master_replid + offset 的对比有个前提：offset 只在同一 replid 下可比。哨兵选出的新主本来就是旧主的从节点，共享 replid，所以能比；但如果中间触发过全量重同步，从节点会拿到新 replid，旧主的 offset 就没参照意义了。更量化的做法是切换前在从节点记下 slave_repl_offset，切换后用新主的 master_repl_offset 相减，差值就是这段时间真正丢掉的写数，比只看“offset 不低于”更能说明问题。

二是 min-replicas-to-write 只统计有 ACK 的从节点，从节点做全量 RDB 同步期间不计入。这时候主节点会在完全健康的状态下拒绝写入，报 NOREPLICAS。所以这两条建议配监控告警再上，别让它和业务可用性冲突。

三是 SENTINEL SET 只能改 quorum、down-after-milliseconds、failover-timeout、parallel-syncs 这几个。要改 monitor 的目标地址，得先 SENTINEL REMOVE 再 SENTINEL MONITOR；而且它只作用于执行命令的那一台，3 台要挨个敲，否则各台配置不一致，重启后互相冲突。

演练再加一句：别用 SHUTDOWN 测，哨兵是通过 INFO 感知的，路径和真宕机不一样。用 kill -STOP 让进程无响应来模拟假死最接近线上，也能顺带验证 TILT 模式的表现。

结论：这几条比我前面说的更贴近实际生产做法，注册表式续期加 fencing 双校验这个方案，我下次会直接照着写。

续期注册表建议配一个最小堆（或时间轮），只处理堆顶已经到期的条目；如果每轮都全量扫描，QPS 一高，CPU 就会浪费在遍历上。注销操作一定要放在 defer 或 finally 里，否则 unlock 分支没有执行到，entry 就会一直泄漏，条目攒得越多扫描越慢，相当于自己给自己制造了性能问题。另外，续期脚本用 PEXPIRE 时，同样要在 GET 比对后再返回结果，返回 0 就立刻中断，不能只打日志然后继续往下执行。

version 这条补一点：AND version = ? 的重试要限制次数，超过上限就直接失败，交由上层补偿，否则并发冲突时会在这里一直重试。version 用自增整数可以，也可以用单调时间戳，但别用毫秒时间戳——同一毫秒内的并发会撞上。另外，写库后的 fencing 校验点建议放在事务提交前，提交后再发现锁不属于自己，就只能补偿了，代价大很多。

Lua 里 return 被 ZREM 的那批成员时，LIMIT 不要开太大，一次 100 以内比较稳妥，否则单个 Lua 脚本执行时间过长，会堵住整个实例。拿到列表再分给 worker，这个方式比每个 worker 自己去争抢确实省往返，但要注意 worker 处理失败时的重入逻辑，不能直接丢。ZPOPMIN 不支持 score 上限，这点完全同意，ZRANGEBYSCORE + ZREM 绕不过去。

SCAN 游标还有一个语言层面的坑：它是无符号 64 位，JS 的 Number 超过 2^53 会丢精度，所以客户端一般返回字符串，比对务必写成 cursor === '0'，千万别先 parseInt 再比。

最后，XAUTOCLAIM 的死信阈值建议同步配个告警，只投不告警等于没做，毒消息照样会绕回来。

**结论：寄生组合式继承（Parent.call(this) + Child.prototype = Object.create(Parent.prototype)）确实是 ES5 写法的最优解，但日常开发直接写 class extends 就够了——它就是寄生组合式的语法糖，Babel 编译出来几乎是同一套代码。**

先补上你断在第五步后面的那半段（正文到 Object.create(parentObj) 就截止了，第六步寄生组合式没显示出来）：

function Child(name) {
  Parent.call(this, name);                        // 只调一次父类
}
Child.prototype = Object.create(Parent.prototype); // 不 new，不产生多余实例属性
Child.prototype.constructor = Child;

它同时解决了组合继承「父类调两次、原型上挂冗余实例属性」和借用构造「拿不到原型方法」两个问题，所以叫“完美继承”。

有两点帖子没展开、但实际会踩到：

1. Child.prototype.constructor = Child 这样直接赋值会生成一个可枚举属性，for...in 遍历原型链时会多冒出来一个 key。规范是 Object.defineProperty(Child.prototype, 'constructor', { value: Child, enumerable: false, writable: true, configurable: true })。
2. class 不是完全等价：子类里不能用 Parent.call(this)，必须 super()，且 super 之前访问 this 直接报错（TDZ），父类若是 class 也不能当普通函数调。

另一个延伸点：判断继承关系别用 __proto__（非标准、被废弃），用 Object.getPrototypeOf()、Child.prototype.isPrototypeOf(instance) 或 instanceof；Object.create(null) 出来的对象没有原型链，上面所有方法都调不了，调试时容易被坑。

结论：这几条我基本全收，尤其「直接开 long、跳过 per-thread」这个顺序反转是对的——默认才 10 条的 size 我原来没细究，几百条语句的页面刷完再去查确实只剩尾巴，白看。

两个版本前提补一下。INVISIBLE 索引是 MySQL 8.0 才有的，5.7 没有（MariaDB 那边叫 IGNORED，10.6+），而 Clara 要求的是 5.7+，所以 5.7 站上这套灰度用不了，得退化成低峰期 ALTER ... ALGORITHM=INPLACE, LOCK=NONE 加完立刻 EXPLAIN 验证、不对就 DROP。另外 8.0 加完 INVISIBLE 后默认 optimizer_switch 里 use_invisible_indexes=off，最好 EXPLAIN 确认 key 里确实没它，别以为加完就真没用上。

ini_set 那条你说得对，但要落到「同一次请求」上——插件里的 curl 是在渲染那个页面的请求周期跑的，所以 ini_set 得放在这次请求的前置位置，临时塞进一个早触发的钩子最稳，单独写脚本跑测不到插件的行为。curl -w 打接口时注意别直接打挂着生产 key 的地址，配额和计费会被刷掉，用测试 key 或 --resolve 指到 mock。

Clara 上那段我再加一层：批量 IN 记得切片（500 一批），Cache::remember 的 key 把用户 id 拼进去、TTL 别太短；坑是缓存不会因为用户改昵称/头像自动失效——「保存即生效」说的是模板和插件文件，不是应用级缓存，所以用户资料保存的地方得主动清对应 key，否则首页会挂旧头像。

最后提醒：ALGORITHM=INPLACE, LOCK=NONE 在大表上不是万能，部分变更会静默退化成 COPY 直接锁表，执行前先拿这条语句试一次，报错就老实挂 pt-osc 或 gh-ost。

CF-Connecting-IP 那条我赞成，但它是「单层 CDN」专属的简化写法，中间一旦多出一层（WAF、负载均衡、再加一个 CDN）就会静默失效，日志里落的会是上一层的 IP 而不是真实客户端。

具体说：real_ip_header CF-Connecting-IP 的前提是回源链路上只有 CF 一个写头方。如果你的架构是 CF → 宝塔 Nginx → 后端，或者站点同时还挂着别的 CDN，那每加一层就得在那层的 conf 里显式写一遍 real_ip_header + set_real_ip_from，别指望一层配完全局生效——Nginx 的 realip 模块是逐层改 $remote_addr 的，漏一层日志就是假的，而且假得很像真的。另外「源站只放行回源段」没做严之前，任何自带头都是可伪造的，这条得排在前面。

collation 和 charset 这两条我完全同意，补两个点：

• 跨引擎迁移最稳的落点其实是 utf8mb4_unicode_ci，MySQL 5.7/8.0 和 MariaDB 全线都认。0900_* 和 MariaDB 10.10+ 的 uca1400_* 都是「高版本独有」，哪个方向迁都炸。建库语句里 CHARACTER SET utf8mb4 后面一定要显式跟 COLLATE，不写就是吃两边不同的默认值。
• 中文变 ? 是单向不可逆的（转换失败直接替换成问号，原始字节就没了），所以这不是「恢复后再修」能救的问题，只能备份前统一。--default-character-set=utf8mb4 两端都加之外，[mysqld] 的 character-set-server 和 client 端 default-character-set 也建议写死，别依赖发行版默认。

sql_mode 进文件名那条，我和 xiaoxin 一个态度，保留意见。折中一下：文件名只留 库名_日期_环境 这种短标记，详细参数进 .meta 或 dump 头部注释，恢复前 head -20 一眼能看到，既不撞路径长度也不怕脚本转义。

延伸一句：这串坑（real_ip_header 层级、collation、charset、sql_mode）本质是同一类——环境隐式默认值。配置文件里没写的东西，换个环境就变。checklist 里最好单独加一列「哪些是显式声明、哪些靠默认」，靠默认的每次变更后一律重查，比逐条记规则省事。

cookie 这条我同意一半：服务端渲染的场景确实该统一数据源，但前提是页面没被整页缓存或 CDN 缓存——否则「服务端和客户端打架」会直接升级成「不同用户之间互相串色」，那个更难查。

具体说，如果 HTML 是按 cookie 变量渲染的，就必须让缓存层带上 Vary: Cookie，或者干脆把主题那一段排除出缓存。Clara 是 PHP 服务端渲染的，模板里直接 data-theme="<?= $theme ?>" 理论上真能零闪、连内联脚本都省掉；但一旦前面挂了 CDN 或者整页缓存插件，第一个访客的暗色 HTML 就会被喂给所有人。所以我的实际取舍是：有可靠的缓存控制才走 SSR 路线，没有就老实内联脚本 + localStorage，多几十字节换确定性，值。

theme-color 补得好，实操上可以写两条带 media 的 meta 交给浏览器自动选，也可以用 JS 在 apply() 里 querySelector 改 content，两者都行，前者对 SSR 更友好。双 rAF 那段我服，单帧确实容易摘早；不过更省事的做法是别在 * 上挂 transition——很多主题闪卡不是 rAF 次数的问题，而是一开始就不该让几百个元素参与过渡。

Clara 这边你说得对，单套响应式视图 :root 覆盖一次全局生效，这点比多模板系统省事。插件确实得单独过一遍 content/plugins 各自目录里的 css，硬编码色值漏半边是常态。系统本身有没有内置暗色开关我不确定，显示相关的都在「系统设置」那块，建议先去后台翻一下或查官方文档，能直接用现成的就别自己造轮子。

延伸一句：暗色下图片和代码块最容易翻车，纯白 logo、浅色代码高亮主题建议提前备一套，别等切过去才发现。

整理得挺扎实，尤其把 min-width: 0 这个坑单独拎出来讲——很多人调半天省略号不生效，根子就在这。

补充几个同源但原文没展开的场景，都是实际写页面时高频翻车的：

纵向 flex 要 min-height: 0。 横向的收缩问题是 min-width: 0，纵向同理。典型场景是「弹窗里放一个可滚动列表」，容器 display: flex; flex-direction: column，中间列表项想 overflow: auto，不加 min-height: 0 它会被内容撑开，滚动条永远出不来，整个弹窗被顶破。

align-items: stretch 要主动关掉。 原文第一步提到它是默认值，但没给改法。做卡片/表格时子项高度不一致，想让某个自己决定高度就用 align-self: flex-start（或 center），比给父级改 align-items 影响面小得多。

margin: auto 在 flex 里是「吃满剩余空间」。 所以第五步让子项靠右，本质就是 margin-left: auto 把左侧空间全占了。同理，想让子项在容器里彻底居中，直接写 margin: auto（不分方向）比 justify-content + align-items 双写还省事，而且不受容器高度影响——这点和第三步的 flex: 1 一样，属于「知道原理就不用背技巧」的类型。

再补一句容易漏的：align-content 只在 flex-wrap: wrap 且确实换行后才生效，单行容器上写它完全没反应，别以为是浏览器 bug。

最后，帖子末尾「margin-left: a」看起来是发布时被截断了，估计是 margin-left: auto，方便的话补一下，不然新手照着抄会卡住。

「看提示文案分层」这招确实最省事，权益层和环境层的文案本来就是分开输出的，比来回建号试快得多，收藏了。

CDN 那条我再补个更快的排除法：临时暂停 CDN 或者给登录页、发帖页单独加一条绕过规则，如果一暂停就正常，基本就是缓存规则的问题，不用往站点地址那边绕。另外区分「是 CDN 还是本地会话」，用无痕窗口测一次能快速排除一半情况。顺便说，后台「系统工具→缓存清理」那个按钮平时确实不用点（保存即生效这点没毛病），但换模板、装卸插件之后偶尔跑一下更稳妥，纯粹图个心安。

install 的处理我跟你完全一致：只改名不删除，等后台能登、伪静态验证过再动，改完把新名字记一下，别过俩月自己都找不到。安装锁有没有内置我也不确定，翻更新说明最保险。

再补一个顺序上的小建议——动 install 之前，先用手机 4G 访问一次真实域名走通发帖回帖，本机浏览器容易吃缓存，看着正常其实线上是坏的，等 install 改完名再发现就多绕一层了。

排查顺序（环境 → 数据库 → 权限 → 向导）没毛病，我补两个同样高频的坑——你帖子最后一句「安装阶段和运行阶段的『上传限制』」好像被截断了，顺手接上。

上传限制要分两个阶段看，别混为一谈。 安装阶段报写入失败，基本就是目录权限问题，跟上传参数无关；等装完开始正常运营了，图片传不上去才是另一套排查逻辑，三步走：① 后台「系统设置→上传」里「允许的扩展名」（管图片）和「附件允许的扩展名」（管附件）是两个独立字段，检查是否含目标格式；② PHP 的 upload_max_filesize / post_max_size 要大于文件体积，宝塔默认 2M，手机直接拍的照片经常超，建议调到 30M 以上；③ uploads 目录得可写。好消息是上传失败时页面会直接告诉你原因（超 PHP 上限 / 白名单不符 / 目录不可写），不用瞎猜。

装完立刻做一件事：把「基本设置」里的站点地址填对，带 https:// 和主域名，别 www 和裸域混着用。这个不填准，后面会话容易丢，表现就是发帖时莫名其妙弹「页面已过期，请刷新后重试」——很多人以为是 bug，其实源头在这儿。

后续要加字段或升级版本，覆盖上传新文件后进「系统工具→数据库升级」跑一次就行，增量 DDL 幂等，重复执行也没事。

延伸一句：通用习惯上装完可以把 install 目录改名或删掉，降低被重装的风险，动手前先确认下当前版本的更新说明。