工程师如何在 X 上写好技术短文
技术 X（Twitter）擅长传播观点密度高的内容，但不适合替代文档。以下为社区长期沉淀的写作惯例整理。
一条 = 一个可检验观点
高赞帖通常只做一件事：给出结论 + 最小证据。例如：「在 Kotlin 里用 supervisorScope 隔离子任务失败——片段见下图」。反例：线程串里塞五个互不相关技巧。
线程结构模板
- Hook：问题场景（「线上 OOM 排查」）
- 转折：常见误区
- 做法：3–5 步可执行清单
- 收尾：邀请反驳或补充
证据链比语气重要
社区对「玄学优化」容忍度越来越低。带 Benchmark 数字、PR 链接、官方 Issue 的帖子传播更远。没有数据时，明确标注「 anecdotal / 个人体验」反而更可信。
代码截图的排版
- 深色主题统一
- 裁掉无关侧边栏
- 关键行高亮（社区常用 redacted 风格）
从推文到博客
优质 X 线程适合变博客，但要扩写上下文：前置知识、失败案例、对比方案 B。本博客「收藏」分类即承担此角色。
不建议发的内容
- 未脱敏的线上日志与用户信息
- 引战式「X 语言已死」
- 纯转发无评论的链接堆砌
好技术短文像好的 commit message：让人愿意点开 diff。