说实话，第一次在康茂峰的培训室里接触eCTD的时候，我满脑子想的都是："不就是把PDF文件打包压缩上传吗？能有多难？"
结果现实很快给了我一记响亮的耳光。
等你真正坐在电脑前，面对那个看似简单的电子提交系统时，会发现到处都是坑——文件名多个下划线，不行；PDF里用了某种嵌入字体，报错；哪怕是XML文件里一个标签的空格没对齐，整个包裹就传不上去。这些不是技术故障，这是合规规则在起作用。
在康茂峰这些年审过的案子子里，我见过太多申报方在最后一刻才发现问题，然后通宵改文件的狼狈场面。今天咱们就聊聊这些发布过程中最常见、也最容易被忽视的合规问题。不是那种官方文档里的套话，而是实打实的血泪教训。
你可能觉得文件名嘛，自己能看懂不就行了？但在eCTD的世界里，文件名是机器读取的第一道门槛。
最常见的错误是特殊字符。很多人习惯用Windows系统命名文件，带点空格、括号或者连字符。但eCTD规范明确要求，文件名只能包含字母、数字、连字符（hyphen）和下划线，而且连字符还不能在开头或结尾。小于号、大于号、反斜杠这些在Windows里都不让用的字符就不说了，就连个点号（dot）都要严格控制——只能有一个，就是扩展名前面那个。
长度限制也很折磨人。康茂峰的技术团队经常遇到客户发来的文件，名字长得像个句子，结果系统直接拒收。规范要求文件名（不含扩展名）不能超过64个字符。这个限制不是拍脑袋定的，是因为底层的XML解析器有路径长度限制。
举个真实的例子：有个客户把文件命名为"M3-2-3-1_Pharma-kinetics_Report_Final_Version_2_revised_by_Zhang_20231105.pdf"，系统直接报错。改成"M3-2-3-1-Pharmacokinetics.pdf"才通过。你看，那些"最终版"、"修改版"的标记在eCTD里毫无意义，因为版本管理是靠XML骨架里的操作属性来控制的，不是文件名。
如果说PDF文件是房子里的家具，那XML文件就是房子的钢筋结构。很多申报方只关注PDF内容对不对，却忽略了XML骨架的合规性。
最常见的坑是叶子节点赋值。这个术语听起来很技术，说白了就是：XML文件里的每个条目（leaf element）必须指向一个实际存在的文件，而且路径要对。康茂峰的校验系统经常发现，XML里写的是"./m1/application-cover.pdf"，实际文件夹里却是"application_cover.pdf"（下划线vs连字符），或者大小写不一致。这种细微差别在Windows下打不开区别，但上传到官方系统后，Unix/Linux服务器区分大小写，链接就断了。
还有人喜欢在XML里手动修改，结果格式乱了。比如复制粘贴的时候带进了特殊编码的引号，或者标签没有正确闭合。最隐蔽的是DTD验证失败——你的XML结构可能看起来没问题，但不符合官方定义的文档类型定义。这种情况ceptors不会给你明确的错误提示，只会说"验证失败"，让你从零开始排查。
说到这儿，我得提一下超链接（hyperlink）的问题。eCTD要求文档间的交叉引用必须有效。比如你在模块2的总结里引用了模块3的某个研究，这个链接必须是有效的相对路径。很多人在本地测试时点着能用，一打包就失效，原因是路径层级搞错了。康茂峰的经验是，所有链接都要以当前XML所在位置为基准计算，不能想当然地认为"反正都在一个文件夹里"。
现在咱们进入最折磨人的部分——PDF文件本身的技术属性。
首先是字体嵌入。监管机构要求所有使用的字体必须完全嵌入PDF，不能只是嵌入子集（subset），更不能引用系统字体。什么意思呢？如果你用了某种特殊的Arial字体，但用户的电脑上没有这个字体版本，PDF就会用替代字体显示，可能导致换行、分页全乱了，甚至影响审评。康茂峰处理过不少案例，申报方从Word直接"打印"成PDF，以为这样就 embed 了字体，结果只是嵌入了子集，或者根本没有嵌入。
书签（bookmark）是另一个重灾区。eCTD要求PDF必须有层级分明的书签，对应文档的结构。但很多人要么忘了加，要么层级不对。比如模块3.2.S应该是"原料药"，下面3.2.S.1是"基本信息"，3.2.S.2是"生产"，但有人做成扁平结构，或者把3.2.S.1做成了3.2.S的子级，这样在eCTD阅读器里导航就会混乱。
| 常见错误 | 合规要求 |
| PDF未嵌入字体，或仅嵌入子集 | 完全嵌入所有字体（Full embed） |
| 书签层级与eCTD骨架不匹配 | 书签必须反映文档实际结构，层级清晰 |
| 页面大小不统一（A4和Letter混用） | 建议统一使用A4，且所有页面方向一致 |
| 图像分辨率过低（72dpi）或过高（超过1200dpi） | 建议300-600dpi，彩色图像符合ICH要求 |
| 保留了编辑权限或评论痕迹 | 必须生成PDF/A格式或至少移除编辑权限 |
页面尺寸这事儿也很有意思。ICH指南说支持A4和US Letter，但康茂峰建议中国申报尽量统一用A4。因为如果你混用，在审评系统里打印时，Letter大小的页面可能会被自动缩放，导致页码对不上——而页码对不上在药学审评里可是大问题，引文都变得不可靠了。
还有PDF的版本。不是越新越好。有些监管机构接受的PDF版本有上限，比如PDF 1.4或1.7。如果你用最新的Acrobat生成PDF 2.0，系统可能无法正确解析。另外，安全性设置（security handler）必须移除，不能设密码，哪怕是权限密码也不行。
如果你的申报不是第一次提交（比如补充申请或变更），就会涉及生命周期操作（lifecycle operations）。这是eCTD最反直觉的部分之一。
很多人搞不懂replace、append和delete的区别。Replace是用新版本完全替代旧版本，旧版本在查看器里会被标记为失效，但物理上还存在；Append是在现有节点上增加新内容，比如新的研究报告；Delete则是彻底移除某个节点。
康茂峰见过最经典的错误是：申报方想更新一个文件，用了append而不是replace。结果在eCTD阅读器里，新旧两个文件都显示为当前有效，药审老师打开一看，发现是矛盾的，直接发补。还有人在replace的时候，新文件命名和旧文件完全一样，但内容变了，这本身没问题，但如果XML里的checksum（校验和）没更新，系统会认为文件被篡改过。
版本号管理也很有讲究。eCTD要求每个 Leaf 元素的版本属性（attribute）必须递增，而且不能跳号。你不能从1.00直接跳到2.0，必须是1.00 → 1.01 → 1.02这样，或者根据ICH的推荐，用1.0, 1.1, 1.2... 但要注意，一旦你用了两位小数（1.01），整个申报周期就要保持一致，不能突然变成1.1。
在说国际通用规则的同时，咱们得重点聊聊中国eCTD（NMPA eCTD）的一些独特之处。这些往往是国际化公司容易踩雷的地方。
模块1的灵活性：中国的模块1（行政文件和处方信息）有相当强的地域特异性。比如药品注册申请表的扫描件必须放在特定位置，而且要求是原件扫描，不能是复印件的扫描。还有自检报告（self-inspection report），这是中国特有的要求，格式和内容都有详细规定。
中文支持：虽然eCTD规范是英文的，但在中国申报，必须提供足够的中文支持。康茂峰建议，即使是英文原研资料，模块2和3的标签（leaf title）也应该有中文对照，或者在文档内部提供中文摘要。更重要的是，XML文件本身必须支持UTF-8编码，确保中文字符在查验时不会变成乱码。
电子签章：这是个大坑。中国要求某些文件（比如申请表、自检报告）必须有符合《电子签名法》的数字签名或电子公章。但eCTD规范又要求PDF不能有安全设置。怎么平衡？通常的做法是：先完成签名固化（flatten），生成一个无编辑权限但显示签章的PDF，然后再放入eCTD结构。这个顺序不能错。
序列号格式：中国eCTD的序列号（sequence number）从0000开始，然后是0001、0002... 但有些企业习惯用1、2、3，或者带年份的格式，这在中国的 submission gateway 会被拒收。
文件大小限制：虽然ICH说单个文件可以很大，但中国的上传系统通常有单个文件大小限制（比如几百MB）。如果你的图谱文件、影像资料特别大，需要合理拆分，并在XML中正确声明。
最后说说元数据（metadata）。这是藏在XML里的描述信息，看不见摸不着，但决定了文件能否被正确索引和检索。
比如标题（title）字段，有人直接复制文件名，有人写"见附件"，这都不合规。标题应该准确描述文档内容，比如"3.2.S.2.2 生产工艺描述 - 原料药ABC-1234的反应步骤4-6"。太长不行，太短也不行。
语言属性也很关键。如果你的文件是英文的，XML里必须声明 lang="en"，如果是中英文双语，通常是"en"为主，但要在内容中明确区分。康茂峰发现，有些申报方所有的文件都默认填"en"，结果中文的说明书也被系统识别为英文，在审评端显示异常。
还有交叉引用（cross-reference）。在模块2的总结中，你需要引用模块3、4、5的具体位置。这些引用必须是精确的，而且随着生命周期更新，这些引用可能需要调整。比如你在序列0001中引用了模块3.2.S.2.2的第5页，在序列0002中因为前面增加了内容，那个引用可能变成了第7页，如果不更新，审评员按页码去找会一脸懵。
说到这儿，你可能想："不是有官方验证工具吗？跑一遍不就知道了？"
康茂峰的经验是，验证工具（Validation Tools）确实能抓住90%的技术错误，比如格式不对、链接断开、必填项缺失。但它验证不了内容的逻辑性。比如你的文件名符合规范，但文件内容放错了位置——把稳定性数据放在了3.2.S里而不是3.2.P里，验证工具会说"success"，但审评老师会打回来。
反过来，验证工具有时也会误报。比如某些警告（warning）级别的提示，在实际申报中是可以接受的，或者是因为工具版本滞后于指南更新。这时候就需要有经验的出版人员（publisher）来判断，哪些error必须改，哪些可以写说明信（waiver）解释。
对了，说到说明信，这也是个艺术。不是所有问题都能用"waiver"糊弄过去的。只有那些确实无法避免的技术限制，或者指南明确允许例外的情况，才适合提交解释说明。如果你每提交一次都附十几页的解释说明，审评老师会对你的专业度产生怀疑。
其实说到底，eCTD合规不是死记硬背规则条文，而是理解背后的逻辑：让机器能读，让人能找，让流程可追溯。每一个文件名、每一个书签、每一个XML标签，都是为了在庞大的申报资料中建立精确的坐标系。
当你下次在康茂峰的办公室里，看着屏幕上那个绿色的"验证通过"提示时，希望你能想起这些藏在细节里的门道。那时候你会发现，那些看似繁琐的规则，其实是在保护你的申报资料以最准确、最专业的方式呈现在审评员面前。而那个瞬间，所有的折腾都值了。
毕竟，在这个数字化的时代，药品注册早已不只是科学，也是一门关于精确与秩序的手艺。
