技术博客
很多人搜 sticky 和 scroll 的区别，其实是混淆了概念：sticky 是 position 属性的合法取值（如 position: sticky），而 scroll 根本不是 position 的可选值——它属于 overflow 或滚动行为相关的关键词（比如 scroll-behavior、scroll-snap-type），也出现在 JS 的 window.scroll() 等 API 中。两者不在同一语义层，不能直接对比“定位效果”。真正该比的是 sticky 和 fixed、relative 这类定位行为。
很多线上问题源于本地开发用 go1.21，但服务器只装了 go1.19，导致 io.ReadAll、slices.Contains 等新 API 编译失败。务必在服务器上执行：
go 标准库的 `encoding/json` 不支持重复键检测，但可通过基于事件的流式解析器（如 `garyburd/json`）实现：遍历 json 令牌时维护对象键哈希表栈，遇重复键立即返回错误。
固定列数（比如 repeat(3, 1fr)）在卡片数量少于 3 时会留白，多于 3 时又换行错位。真正要的是“尽可能塞满容器宽度，每张卡有最小宽度、最大能等分”，必须靠 auto-fill + minmax() 组合。
日志暴涨往往不是孤立现象，而是系统异常、配置错误或业务突增的外在表现。单纯切日志只能缓解磁盘压力，不解决根源反而可能掩盖真实问题。排查要“先看因、再动手”，切割和限流是控制手段，不是替代诊断的捷径。
百分比是相对于父容器尺寸计算的，如果父容器本身没设宽高（比如 body 或 div 没设 height），子元素用 height: 100% 就会失效或塌陷；更常见的是图片、视频、卡片在宽高比变化时被强行拉伸——这不是百分比错了，是没约束宽高比。
大型项目里，@import 在 CSS 文件中引入其他样式表，会阻塞并串行加载，导致关键 CSS 延迟解析。浏览器无法并行下载，还可能触发 FOUC（Flash of Unstyled Content）。
MySQL 的执行计划（EXPLAIN 输出结果）不是在客户端拼接 SQL 时生成，也不是在存储引擎读数据时才决定，而是在 Server 层的查询优化器（Query Optimizer）完成逻辑解析和语义检查之后、实际执行之前生成的。具体来说，它发生在：parser → resolver → optimizer → executor 这一链条中的 optimizer 阶段。
当IN查询参数超过2100个（SQL Server限制），Dapper原生语法 WHERE Id IN @Ids 会直接报错——这不是Dapper的缺陷，而是SQL Server底层协议（TDS）对单条命令参数数量的硬性约束。绕过它需要改变数据传递方式，而非拼接字符串。
根本原因在于它只匹配「是其父元素倒数第 N 个子元素」且「类型匹配」的元素，而不是「在视觉上倒数第 N 个满足某条件的元素」。比如父容器里有
、 混排，p:nth-last-child(2) 只会命中那个恰好位于倒数第二个位置的
—— 如果倒数第二个是 ，那就什么也不选。 :nth-last-child(n) 的参数写法和常见陷阱