· 全部指南
Markdown 在工作流中的位置
Markdown 已成为 README、内部 wiki、开发者博客以及 GitHub、GitLab 等平台评论系统的默认书写格式。纯文本语法便于版本管理，但渲染结果高度依赖工具链支持的方言。GitHub Flavored Markdown（GFM）扩展了任务列表、表格与删除线；CommonMark 则追求更严格的规范。发布文档前务必预览 HTML 输出，避免格式意外。
markdown-converter 可在浏览器内在 Markdown 源码与 HTML 之间切换，无需推送到预发环境即可检查标题、代码围栏与链接。更新 README 的推荐流程：撰写 Markdown 草稿 → 粘贴到 markdown-converter 预览 → 确认列表与代码高亮正常 → 提交 .md 文件。若静态站点生成器（Hugo、Jekyll、VitePress）使用不同解析器，再用含表格与嵌套引用的样例做第二次预览。
实例：贡献者在表格单元格写了 **粗体**，但渲染器不支持表内行内格式，预览显示原始星号而非样式，提示你调整结构。另一常见情况：代码块未标语言——补上 ```json 后多数渲染器才能语法高亮。
HTML 实体与清洗
用户生成的 Markdown 转为 HTML 时，安全是首要问题。切勿在 Web 应用里把未净化的 HTML 赋给 innerHTML。攻击者可在链接、图片中嵌入 <script> 或事件处理器；即便 Markdown 解析器去掉 script，像 <script> 这样的实体技巧仍可能绕过简陋过滤器。
html-entities 负责编码/解码 &、<、" 等实体，在用户内容嵌入 HTML 模板或邮件时必不可少。html-to-text 剥离全部标签，生成适合邮件预览、搜索索引或通知摘要的纯文本。推荐净化流程：Markdown 解析为 HTML → 经白名单净化器（如 DOMPurify）→ 非纯 HTML 上下文再做实体编码 → 最后渲染。
常见错误：只信任客户端净化（服务端必须再净化一次）；双重编码导致页面 literal 显示 &amp;；只存 HTML 不保留 Markdown 源——未来升级解析器将无法准确重渲染。
与 CMS 集成
现代内容系统通常以 Markdown 为源、编译为缓存 HTML 展示。这样模板变更时可批量重渲染而无需逐篇改稿。流水线应保留带语言标识的围栏代码块（```python），以便加载正确语法高亮。target="_blank" 的外链应加 rel="noopener noreferrer"，防止 tab-nabbing。
集成示例：无头 CMS 通过 API 下发 Markdown 正文。前端拉取原文，编辑本地预览时走 markdown-converter；构建步骤编译为 HTML 上 CDN。迁移平台时用 text-diff 对比新旧 HTML，捕捉丢失的脚注或 heading anchor 变化导致的内链断裂。
Towalles 本地优先
Towalles 的 Markdown 与 HTML 转换完全在浏览器完成。草稿文档、客服回复、迁移测试不会为计算而上传到 Towalles 服务器。本地优先适合内部 runbook 以及不宜粘贴到陌生在线转换器的客户数据片段。
面向用户的文案发布前，可用 readability-scorer 估算阅读难度与句子复杂度。大篇幅 Markdown 的 PR 审查可配合 text-diff，高亮变更段落而无需滚动数百行未改内容。注意：本地处理不消除剪贴板风险——处理敏感草稿后清空输入，录屏时避免窗口仍显示客户姓名或示例代码中的 API 密钥。