技术博客
Go 官方生态里 blackfriday 确实曾是 Markdown 渲染主力，但它早在 2020 年就正式归档（archived），不再维护。现在直接 go get github.com/russross/blackfriday/v2 虽能装上，但遇到 CommonMark 兼容性问题、安全更新缺失、HTML 实体处理异常时，没人修。
SQL报表出现数据倾斜，本质是某些键值的数据量远超其他，导致计算任务集中在少数节点，拖慢整体响应。分桶（Bucketing）不是万能解药，但它是从存储层就控制分布、预防倾斜最直接有效的手段之一。
多表关联查询是SQL中最常用也最容易出问题的部分。写得不好，轻则结果错乱、性能骤降，重则拖垮整个数据库。关键不在“会不会写JOIN”，而在于理解每种JOIN的语义边界、明确业务意图、并提前预判数据分布对执行的影响。
根本原因不是PHP类型错了，而是MySQL的int有符号范围是-2147483648到2147483647，而PHP在32位环境里int最大值也是2147483647。一旦你传入超限值（比如3000000000），MySQL会静默截断为2147483647（有符号上限）或0（溢出后归零，取决于SQL模式）。
HTML 图片默认是行内元素，会和文字基线对齐，导致下方留白——这不是 bug，是 CSS 默认行为；想精准控制位置，得用 vertical-align、display 或 flex，而不是靠 align 属性（已废弃）。
直接调 wkhtmltopdf 是目前最可控的 HTML 转 PDF 方式，尤其适合生成带样式、分页、页眉页脚的文档。但它默认不加载远程字体（比如 Google Fonts）、不执行 JS 渲染动态内容、对相对路径的 CSS/JS 解析也容易出错。
直接用 LIKE ‘关键词%’ 看似能走索引，但实际常比预期慢——尤其当关键词短、匹配行多时。根本原因是：索引只加速“定位起始位置”，不加速“后续扫描”。如果前缀太短（比如搜 ‘a%’），MySQL 得从索引里扫出几万行再回表，I/O 和 CPU 都吃紧。
MySQL 单表恢复没有“一键回滚”功能，实际取决于你有没有对应备份以及备份类型。如果只有全库 mysqldump 文件，恢复单表就得从 SQL 文件里抽取出目标表的 CREATE TABLE 和 INSERT 语句；如果开启了 binlog 且格式为 ROW，才可能用 mysqlbinlog 精确过滤出该表的变更并反向应用。
会，但不是“立刻”或“无条件”释放——ROLLBACK 执行完成的那一刻，该事务持有的所有行锁、表锁（含意向锁）都会被清除。这是 InnoDB 的硬性保证：事务生命周期结束，锁生命周期同步终结。但要注意，**锁的释放发生在回滚操作“执行完毕后”，而非“回滚语句发出时”**。如果回滚本身因大事务、大量 undo 日志回放而卡住（比如几十万行更新后回滚），那锁就持续阻塞着其他事务，直到回滚真正完成。
元素没设 top（或 bottom）值，或者父容器没设置高度/溢出限制，position: sticky 就直接退化成 static。它不是“自动吸顶”，而是依赖触发阈值和容器边界共同生效。