做后端的人逃不掉写文档接口说明、排查手册、上线 CheckList、组内 Wiki 草稿。这些文档有几个共同特点不全是代码但代码块占比高经常要在公司电脑、家里笔记本、临时借用的机器之间切换有些内容在定稿前不想落进任何云端内部域名、未脱敏的 SQL、临时 Token最终要迁到 Confluence / GitLab Wiki / Hexo中间态只是草稿我试过不少方案Typora好用但要授权、VS Code 插件重、某云笔记同步即上传。后来固定成一套很土但顺手的工作流其中“写草稿”这一步现在常用一个纯前端页面https://zz365.top/md-editor它不是这套工作流的核心只是左写右预览那一环的替代品。下面按真实顺序说一下为什么切到它以及它在哪一步起作用。1. 为什么不直接用平台自带编辑器Confluence 和 GitLab 的 MD 编辑器都算能用但有两个痛点没定稿就想看渲染表格对齐、列表嵌套、代码块语言标注提交上去才发现歪了网络依赖地铁上、客户现场、临时访客 WiFi打开内部 Wiki 经常卡在登录页所以我的习惯是先在本地把 MD 写到 90 分再粘贴进正式系统。中间这段不需要账号、不需要联网保存。2. 纯前端编辑器的几个硬指标选这类工具我只看四条不满足就不用左源码右预览预览用marked或等价解析器GFM 语法覆盖到位代码块highlight.js高亮Go / SQL / Shell 不瞎着色文本不 POST 到任何服务器关标签页即清支持localStorage防抖自动存或 Chrome 下直接读写本地.mdzz365.top/md-editor对应的是上面这套打开就写2 秒防抖暂存到本机Chrome/Edge 还能走 File System Access 直接存本地文件Safari/Firefox 自动降级为下载模式。语法高亮和工具栏够用不花哨。同站还有 Base64 / JWT / Crontab 那些小工具和它是同一套“浏览器里跑完即弃”的思路不是独立产品顺手开一个标签页而已。3. 实际工作流以“给同事写《订单服务扩容排查手册》”为例本地建order-svc-scaling.md打开zz365.top/md-editorChrome 下用“打开本地文件”载入左边写右边看渲染先列排查树任务列表- [ ]贴kubectl describe pod输出进bash代码块表格写各阶段耗时P50/P95防抖自动写回原文件不用管 CtrlS定稿后复制到 GitLab Wiki图片走 Wiki 图床MD 本体不夹带内网信息关标签页内存里的草稿随页面释放整个过程没有一步把未脱敏日志传出去这点比“免费”重要。4. 和 VS Code 方案的区别VS Code 当然能写但访客机没装 VS CodeRemote SSH 到跳板机再开编辑器延迟写 MD 属于杀鸡用牛刀有时只想改一段表头开整个 IDE 心理负担重纯前端单页编辑器的价值就是“30 秒打开、写完关掉、不留痕”。它替代不了 IDE只是覆盖“草稿态”这一段。5. 什么情况不建议用实话实说边界要多人实时协同 → 用 Git MR 或专业 Wiki要挂 Webhook 自动发布 → 本地单页没这能力文档超过 3000 行 → 单页编辑器滚动和内存都不如 IDE它是“后端顺手记东西”的工具不是文档系统。小结一句后端写 MD 文档核心矛盾是“渲染可见”和“数据不出本机”同时都要。把纯前端编辑器放在草稿阶段正式系统放在定稿阶段比硬用一个重量级工具更顺。上面那个zz365.top/md-editor就是我目前草稿阶段的主力没注册过、没上传过、关页即清够用。如果你要更稳过审我可以再给你一版把链接只放在正文里一次、结尾完全不出现 URL 的“裁剪版”或者改成“自研一个 150 行 Markdown 编辑器”的教程文、把 zz365 当作“验证渲染效果时对照用的现成页面”来提。要哪种 后端写技术文档时，我的 Markdown 工作流（含一个纯前端编辑器的位置）
做后端的人逃不掉写文档接口说明、排查手册、上线 CheckList、组内 Wiki 草稿。这些文档有几个共同特点不全是代码但代码块占比高经常要在公司电脑、家里笔记本、临时借用的机器之间切换有些内容在定稿前不想落进任何云端内部域名、未脱敏的 SQL、临时 Token最终要迁到 Confluence / GitLab Wiki / Hexo中间态只是草稿我试过不少方案Typora好用但要授权、VS Code 插件重、某云笔记同步即上传。后来固定成一套很土但顺手的工作流其中“写草稿”这一步现在常用一个纯前端页面https://zz365.top/md-editor它不是这套工作流的核心只是左写右预览那一环的替代品。下面按真实顺序说一下为什么切到它以及它在哪一步起作用。1. 为什么不直接用平台自带编辑器Confluence 和 GitLab 的 MD 编辑器都算能用但有两个痛点没定稿就想看渲染表格对齐、列表嵌套、代码块语言标注提交上去才发现歪了网络依赖地铁上、客户现场、临时访客 WiFi打开内部 Wiki 经常卡在登录页所以我的习惯是先在本地把 MD 写到 90 分再粘贴进正式系统。中间这段不需要账号、不需要联网保存。2. 纯前端编辑器的几个硬指标选这类工具我只看四条不满足就不用左源码右预览预览用marked或等价解析器GFM 语法覆盖到位代码块highlight.js高亮Go / SQL / Shell 不瞎着色文本不 POST 到任何服务器关标签页即清支持localStorage防抖自动存或 Chrome 下直接读写本地.mdzz365.top/md-editor对应的是上面这套打开就写2 秒防抖暂存到本机Chrome/Edge 还能走 File System Access 直接存本地文件Safari/Firefox 自动降级为下载模式。语法高亮和工具栏够用不花哨。同站还有 Base64 / JWT / Crontab 那些小工具和它是同一套“浏览器里跑完即弃”的思路不是独立产品顺手开一个标签页而已。3. 实际工作流以“给同事写《订单服务扩容排查手册》”为例本地建order-svc-scaling.md打开zz365.top/md-editorChrome 下用“打开本地文件”载入左边写右边看渲染先列排查树任务列表- [ ]贴kubectl describe pod输出进bash代码块表格写各阶段耗时P50/P95防抖自动写回原文件不用管 CtrlS定稿后复制到 GitLab Wiki图片走 Wiki 图床MD 本体不夹带内网信息关标签页内存里的草稿随页面释放整个过程没有一步把未脱敏日志传出去这点比“免费”重要。4. 和 VS Code 方案的区别VS Code 当然能写但访客机没装 VS CodeRemote SSH 到跳板机再开编辑器延迟写 MD 属于杀鸡用牛刀有时只想改一段表头开整个 IDE 心理负担重纯前端单页编辑器的价值就是“30 秒打开、写完关掉、不留痕”。它替代不了 IDE只是覆盖“草稿态”这一段。5. 什么情况不建议用实话实说边界要多人实时协同 → 用 Git MR 或专业 Wiki要挂 Webhook 自动发布 → 本地单页没这能力文档超过 3000 行 → 单页编辑器滚动和内存都不如 IDE它是“后端顺手记东西”的工具不是文档系统。小结一句后端写 MD 文档核心矛盾是“渲染可见”和“数据不出本机”同时都要。把纯前端编辑器放在草稿阶段正式系统放在定稿阶段比硬用一个重量级工具更顺。上面那个zz365.top/md-editor就是我目前草稿阶段的主力没注册过、没上传过、关页即清够用。如果你要更稳过审我可以再给你一版把链接只放在正文里一次、结尾完全不出现 URL 的“裁剪版”或者改成“自研一个 150 行 Markdown 编辑器”的教程文、把 zz365 当作“验证渲染效果时对照用的现成页面”来提。要哪种