从 Markdown 到 PDF 再回来：格式转换保留什么
Markdown 与 PDF 各为不同契约服务：标题、列表与简单表格能大致往返，精确字体、分页与版面布局会丢失，往返两次还会漂移，不能当作归档循环。
Markdown 和 PDF 优化的契约不同。Markdown 是利于版本控制的结构，PDF 是固定的页面描述。单向转过去再转回来有用，但它不是无损的归档循环。
Markdown 转 PDF：结构变成页面
Markdown 转 PDF（POST /api/v1/convert/markdown/pdf）接受 .md 文件，或一个内含 Markdown 的 ZIP。非 Markdown、非 ZIP 的上传会被拒绝，纯 .md 输入要求 UTF-8。流水线先把 Markdown 渲染成 HTML，启用表格、删除线与任务列表，再用面向打印的 CSS 包起来（含多文种字体栈，检测到阿拉伯语时切 RTL），最后交给 WeasyPrint 打印成 PDF。
正向转换通常能活下来的东西：
- 标题、段落、列表与简单的 Markdown 表格
- HTML 路径排得下的多文种文字（打印 CSS 覆盖的 CJK、拉丁及其他文种）
- 面向文档即代码工作流的可打印、可分享 PDF
活不下来的：
- 编辑器主题字体在每个查看器里的保证匹配
.md文件里精确的屏幕换行- 没有 PDF 对应物的交互特性（实时复选框、可折叠区块、wiki 链接）
ZIP 输入是为了把 Markdown 与能在文档旁解析的资源打在一起，把它当作打包上的便利，别当作“每个相对图片或 CSS 引用在每个查看器里都长得一样”的保证。
PDF 转 Markdown：文本层进，Markdown 出
PDF 转 Markdown（POST /api/v1/convert/pdf/markdown）经 pdf-inspector 把文本内容抽成 Markdown，响应是 text/markdown，以 .md 文件下载。文本层干净的原生数字 PDF 效果最好；没有文本层的扫描页在你先 OCR 之前只会得到空或无用的 Markdown，而本站 OCR 同样返回 Markdown，不是可搜索的 PDF 文本层。
可以预期：
- 字号启发式正常触发时有标题与段落（
#层级仍可能要手工重排） - 识别成功时表格会变成 Markdown 表格，多栏版式可能线性化成另一种阅读顺序
- 每页重复出现的页眉页脚（事后自己删）
- 图像与以图片形式存在的公式不会自动变成本地资源或 LaTeX
若你要的是没有标题启发式的纯散文，PDF 转文本 是更平的抽取。表形导出返回 HTTP 204，意味着没有检测到列块，见 空表格导出（204）。
往返究竟证明了什么
| 大致能存活 | 通常不存活 |
|---|---|
| 词语、标题层级、列表结构 | 像素级精确的页面几何 |
| 作为文本的简单表格 | 精确的字体与字距 |
| 给 Git 或 Agent 的可用草稿 | 与印刷完全一致的分页 |
往返两次就会漂移。Markdown→PDF 要经 WeasyPrint 重新排版，PDF→Markdown 要从抽取启发式重建结构，两步都不保存对方版式模型的无损中间态。
选定一个规范方向
若印刷版面才是你的系统真相，就保留 PDF，把 Markdown 当作导出格式或给 Agent 的输入。若你需要 diff、代码审查与 Agent 摄入，就优先 Markdown，把 PDF 当作发布步骤。别把两者都存成平等的“真相源”，还指望编辑之后它们保持一致。
一个实用的文档即代码循环：在 Git 里改 Markdown → 用 Markdown 转 PDF 产出可分享的成品 → 别把 PDF→Markdown→PDF 养成日常习惯。接手一份原生数字 PDF、又需要给 Agent 喂文字时，才用 PDF 转 Markdown，然后把它当作一份新草稿，而不是原分页的保证。
加密文件在做任一种转换前，都需要授权的 解锁。打不开的损坏文件，先走 获取信息 / 修复。同一批端点的 HTTP 用法见 开发者。