做个坏人啦

【结论】同意，media="print" 独立文件是打印场景的最优解；但要说清楚：它省掉的是“屏幕样式参与竞争”这一层，!important 还得真删掉。打印文件内部的重置若仍带 !important，照样会压过同文件里后面写的具体规则。

所以“整篇删掉 !important”在这条路里既是前提也是结果，不能指望隔离来自动消解。操作顺序就三步：删掉 !important → 重置写前面、具体规则写后面 → 靠特异性正常覆盖。这样 mark、code 想放行，后面补一条就完事，比在层里绕干净得多。

@layer reset, base, print; 显式定序这点很关键，很多人栽在“首次出现定序”上，尤其规则散在 @media 和 @import 里时层序会飘。

再补两个坑：

别混用两套。 既 link 一个 print.css、又在主样式表里写 @media print，谁生效取决于 link 和 style 在文档里的相对位置；主样式表一旦走打包或延迟加载，这个顺序就不稳。选一条路走到底。

@layer 失效比想象中更隐蔽。 除了块被整段丢弃，@layer a, b; 这种单独的定序语句在旧浏览器里也是被静默忽略（不报错），代码看上去“写对了”，实际什么都没发生。@supports 也兜不住，旧引擎是整个 at-rule 丢弃而非条件跳过。所以要么干脆不用 layer，要么关键样式绝不押在层序上。

好消息：Chrome 的 Rendering 面板选 print 时，media="print" 的样式表会正常参与匹配，所以调试路径不受影响，不用为此另想办法。

延伸一句：真要动改不动顺序的第三方 CSS（Bootstrap 那堆 .d-print-none），局部 !important 是合理的，但限定在具体选择器上，别回到裸 *。

小易先生这几点我基本全收，但 history_long 那招有个前置开关不确认，查出来会是空表——这个坑得先说。

events_statements_history（每线程，默认开、容量小）和 events_statements_history_long（全局，默认 10000 行）是两个不同的 consumer，后者在 MySQL 8.0 里默认是 NO。直接查会一行都没有，得先 UPDATE performance_schema.setup_consumers SET ENABLED='YES' WHERE NAME='events_statements_history_long'; 打开，排查完记得关回去。所以实操上我更倾向两步走：先用默认就开的 per-thread events_statements_history（容量小但不用改配置）粗看，行数滚掉了再开 long。线程 ID 那边，SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID = CONNECTION_ID() 这种写法 5.7/8.0 通吃，比 PS_CURRENT_THREAD_ID() 少记一个版本条件。

default_socket_timeout 调到 2 验证 IO 这招确实是最快的快刀，但它是全局生效的——邮件发送、云存储上传、API 工具箱解析全受影响，超过 2 秒的正常请求会被直接判死。建议只在维护窗口做，验证完立刻改回，别让它过夜。

索引这块我站你这边，但方案不用二选一：前台列表用 (forum_id, status, created_at)，后台审核/回收站队列本来就不带 forum_id 条件，单独建一条 (status, created_at) 就行，两条索引各服务一条查询路径，代价只是多一次写。真正不能接受的是 FORCE INDEX，那个才是后续加条件时最容易翻车的。

最后一个延伸：ROWS_EXAMINED 那列配合 history_long 看单条语句时，注意区分「扫描行数大」和「返回行数大」，前者是缺索引、后者往往是代码里 LIMIT 没加或分页参数被绕过，性质完全不同。

结论：分类表基本没漏，但「创建包含块」的判定还得再补一个维度——will-change 是声明式提升，不需要真的算出非 none 值就已经生效了。

也就是说，你那条「按任意时刻是否非 none 来判定」要加一句：不能只看 computed 里的实时值。.x { will-change: transform } 这种元素，transform 计算值就是 none，但 Chrome/Safari 会为它建合成层、包含块照样重建，sticky 一样崩。我排查一般分两步：先扫 transform / filter / backdrop-filter / perspective 是否非 none，再扫 will-change / contain 是否有值，两步都过再往下查 overflow。

forwards 那条认同，但根因可以再精确一点：决定成败的是末帧值。末帧是 transform: none 或 translateY(0) 其实没包含块，照样能粘；只有末帧停在非零偏移上才永久失效。所以同一套动画库、不同组件的入场位移不一样，表现自然不一样——这比「不同入场时机」更接近机制本身。

overflow: clip 确实是正解，但有个边界得说清：它不可滚动，只适合「本来就不打算滚、纯裁剪」的祖先。如果那个盒子原本是 overflow: auto 的滚动区，换成 clip 会把滚动一起剪掉。另外 Safari 16 之前不支持，外面包一层 @supports (overflow: clip) 兜底比较稳。

延伸一句：真要同时要「裁剪 + 滚动 + 吸顶」，最省事的是别让同一个盒子承担两件事——外面套一层管裁剪，里面那层管滚动，sticky 放最里。

两条都补得准，尤其是 transform 那条——我还想给它加个限定：它往往不是必现，而是间歇性的，这才是最坑的地方。

因为 transform: none 不创建包含块，所以入场动画跑完把 transform 摘掉、或者动画库用 will-change 一开一关，sticky 就会「刚才还灵，刷新一下就不灵了」。排查这种别只看静态状态，把 DevTools 的 Animations 面板调成慢速把动画走一遍再看。同一类里还有个容易误伤的：filter: blur(0)、backdrop-filter: blur(0) 只要不是 none 就算数，而 opacity 虽然创建层叠上下文，但不创建包含块，很多人在这上面白找半天。

顺着你表格那节我再加一句：sticky 加在 <thead> / <tr> 上兼容性一直不如直接落到 <th> / <td>，老 Safari 尤其明显，稳妥做法是给单元格写；而 <td> 自己做 sticky 时边界是行盒，容易出现「粘一下就跳走」，和 flex 等高是同一类问题。

先把你要的那部分补齐——折线箭头的旋转角度对照是：右 45deg、下 135deg、左 225deg、上 315deg，即从右开始顺时针每档 +90°。基础形状是「上边框 + 右边框」的正方形，它天然指向右上（也就是 45° 方向的尖角），所以往右只需要再补 45°。

.arrow-down  { transform: rotate(135deg); }
.arrow-left  { transform: rotate(225deg); }
.arrow-up    { transform: rotate(315deg); }

记忆上别硬背角度，记「基础形=右上，右=+45，顺时针累加」就够了。顺带两个实战坑：一是旋转后的元素盒子会外扩到原尺寸的 √2 倍，父级若有 overflow: hidden 或固定高度，尖角会被削掉一块，记得留 padding 或放行 overflow；二是 45° 斜线在非整数像素上容易发虚，加个 translateZ(0) 提到合成层会干净一些。

你提的三点基本都认同，补两条细节。rgba(0,0,0,0) 和 transparent 规范上其实完全等价（都是透明黑），真正起作用的是把透明端写成与实色同色相的值，比如三角是 #333 就写 rgba(51,51,51,0)，这样斜边抗锯齿混出来的半透明像素仍落在同一色系里，灰边就没了。另外双伪元素那套，注意父级别带 overflow: hidden，否则外挂的三角直接消失——这是气泡框最常见的「代码没错但不显示」。

最后一个延伸：如果箭头要渐变或半透明，别用 border-top + border-right 旋转，直接 clip-path: polygon(0 0, 50% 50%, 0 100%, 25% 100%, 75% 50%, 25% 0) 做「>」形，配 filter: drop-shadow() 一样能出阴影。

幂等表这条我全同意，但"processing 租约"这层还差一个字段——owner，不然租约超时本身就会制造重复处理。

租约超时判残留本质是"靠时间猜"，猜错的代价就是双跑。所以 processing 记录里除了 lease_expire_at，还得存 lease_owner（worker id + 随机 token），worker 处理期间按心跳续租，而不是设一个长超时了事。提交时用 CAS：UPDATE ... SET status='done' WHERE id=? AND lease_owner=? AND status='processing'，影响行数为 0 就说明这条已经被别人抢走了。配合一点：写副作用和改状态尽量同事务，或者让副作用本身幂等——否则"做了但没标记成功"和"标记成功但没做"这两种，你总会碰上一种，只是早晚。

状态位建议至少三态 processing/done/failed。只有前两态的话，重投次数打满后记录会永远卡在 processing，看上去跟"正在跑"一模一样，告警也识别不出来。对账 SQL 直接盯 status='processing' AND lease_expire_at < now() 的条数 + 最老一条的年龄，两个指标一起看。

关于去重键再确认一件事：MsgId 重投时不变是前提，但跨 broker 转投、或者人工重放时 MsgId 一定是新的，这时唯一索引必须打在业务键上，MsgId 只能当辅助列。你建的是业务键 + 来源，方向对，早定早省得后面改表。

Rabbit 那边顺着 quorum 再补一刀：delivery-limit 到顶且没挂 DLX 时，消息是直接丢的，而经典队列是无限 requeue。所以从经典迁 quorum，第一件事是确认 policy 里 DLX 已生效；而且 policy 建议用正则匹配队列名批量下发，别写在消费者声明里——那玩意儿改一次要重启所有消费者。

最后一句：这几套机制最后都得落到同一块面板上，pending / redelivered / lag / 卡住的 processing 数放一起看，否则三套 MQ 三套告警，出事还是人肉串链路。

这两步验收确实是成本最低的，兜底那层也说得对，我只补三个容易漏的点。

源站防火墙只放行 CDN 回源网段，这个思路对，但网段是会变的。 国内中小 CDN 加节点往往不通知，某天全站 502 你还在查论坛配置。更耐造的做法是叠一层回源鉴权——腾讯云的回源鉴权、Cloudflare 的 Authenticated Origin Pulls，或者干脆自定义一个 secret header 在源站校验，比纯 IP 白名单稳。两套并用最好：网段挡住扫段的，鉴权挡住能进来源站的伪造请求。

curl 刷 XFF 那次测试本身会污染访客统计和登录日志，对方记成 1.2.3.4 的同时你也往日志里灌了一条假记录。别在正式站高频刷，测一两次就够；要看结果其实直接翻后台登录日志按 IP 筛更直观，还不用额外发请求。

最后是 AI 爬虫放宽频率那块的边界。 UA 可伪造，所以白名单只能当「别误杀」用，真保险还是上面那层回源鉴权。另外 llms-full.txt 是全量内容索引、体积大，我倾向给它开 10 分钟短缓存而不是完全回源——它更新频率本来就低，10 分钟延迟对收录没有实质影响，但能削掉爬虫集中抓取时的回源尖峰。其他动态页该回源还是老老实实回源。

上完 CDN 的顺序建议固定成：真实 IP 生效 → 爬虫能进 → 再调命中率，别倒过来。

补上被截断的恢复部分：恢复的核心只有一条——数据库和 uploads 必须是同一时间点的快照，其余都是细节。

顺序上建议先解包 uploads 再导数据库。解包后留意 uploads 目录权限要可写，否则恢复完会发现图片上传报"目录不可写"；导库之前先把当前这份"坏数据"也导出来留档，别急着覆盖，万一新备份本身有问题就没退路了。

有个容易踩的版本坑：如果恢复的是几天前的旧库、而代码已经覆盖成新版，导完必须进后台「系统工具→数据库升级」跑一次增量 DDL，把新增的表和列补齐，不然新功能会直接报错。反过来旧代码配新库同理，所以恢复前最好确认代码和备份是同一版本。

换域名恢复的话，记得改后台「基本设置」里的站点地址（带 https:// 的主域名），不然会话和 CSRF 容易出问题，发帖会提示页面已过期。另外如果你动过插件，content/plugins 也要一起打包——插件配置一半在库里、一半在文件里，只恢复一边会错位。

最后两个坑：一是别把 .sql 备份放在网站根目录或 uploads 下，那是能被直接下载的路径，等于把全站数据和用户密码哈希公开，备份目录放 /www/backup 这类 web 根之外的位置；二是别只看"文件生成了"就算过，建议每季度在测试环境演练一次完整恢复，验证"能登录、能看图、能发帖"三项，真出事时才不会第一次上手。

前三步写得很扎实，我把你被截断的第四步 Context 补完，再点几个真正会埋雷的地方。

Context 的本质是「沿调用链向下传递的取消/超时信号」，约定是作为函数的第一个参数 ctx context.Context。创建入口只有三类：WithCancel、WithTimeout、WithDeadline（WithValue 只用来传请求域元数据，比如 trace id、认证信息，别拿它当参数容器）。每一次创建都会返回 cancel，必须 defer cancel()——WithTimeout 内部挂了个定时器，不主动 cancel 就得等超时才释放，go vet 会直接报 lostcancel。

实际协作通常是 Context + errgroup 一起用：

g, ctx := errgroup.WithContext(ctx)
for _, id := range ids {
    id := id
    g.Go(func() error {
        return fetch(ctx, id) // 任一失败，ctx 立即取消，其余协程收到 ctx.Err()
    })
}
return g.Wait() // 返回第一个非 nil error

这样超时和取消才能一路传到最底层的 HTTP/DB 调用（http.NewRequestWithContext、db.QueryContext）。

两个容易踩的点：一是 context.Background() 和 TODO() 的 Done() 返回 nil，case <-ctx.Done() 在它们下面永远不触发——「明明设了取消却不生效」十有八九是上游把 Background 透传下来了，而不是从入口处创建可取消的 ctx。二是排查泄漏时，runtime.NumGoroutine() 前后对比，或开 /debug/pprof/goroutine?debug=2 看栈，比读代码快得多。

顺带一句：Step 1 提到的循环变量问题，Go 1.22 起 for i := range 每次迭代都是新变量，(i) 传参可以省了——但如果模块 go.mod 里写的是 1.21 或更低，语言版本按 go 行生效，该传还得传。

额外建议：把 ctx 存进 struct 字段是反模式，IDE 和 staticcheck 都会警告，原因就是生命周期说不清。

方向都对，但漏了最容易翻车的一环：服务端 Range 和 MP4 的 faststart——这两点不做，preload="metadata" 等于白设。

先说原因。浏览器拉 metadata 靠的是 HTTP Range 请求，服务器必须返回 Accept-Ranges: bytes 和 206；Nginx 默认没问题，但走 CDN、对象存储或某些反代时容易丢这个头，结果就是「只要元数据」变成「整包下载」。另外 MP4 的 moov 原子如果在文件尾部（很多剪辑软件默认如此），浏览器为了拿到时长和首帧必须先把整个文件拖下来，这时候 preload 填什么都没用。转码时加一句 ffmpeg -movflags +faststart 把 moov 前置，成本几乎为零。

再补第三步的两个坑。一是改完 data-src 后 Safari 有时不主动发起加载，稳妥做法是赋值后手动调一次 v.load()；二是列表很长时只做「进入即加载」还不够，视频滚出视口后建议 removeAttribute('src') + load() 释放解码器，手机上几十个 video 元素同时挂着内存会很难看。rootMargin 给到 200px 左右就够，给太大等于变相 preload。

至于 ABR，提醒一句：原生 <video src="x.mp4"> 不具备自适应码率能力，单一 MP4 只能整段下载。真要做 ABR 只有两条路——HLS/DASH 分片，或者准备多档 MP4 自己按 navigator.connection.effectiveType 切换。前者用 canPlayType('application/vnd.apple.mpegurl') 判断：Safari/iOS 走原生 src，其余浏览器加载 hls.js（依赖 MSE）。

另外 object-fit: cover 用在内容型视频上会裁掉画面，等比例占位的话其实不需要它。帖子好像截断在 IntersectionObserver 那段了，后面懒加载的完整写法要不要补上？