XML解析器默认保留Comment节点，但不同解析器可见性策略不同：ElementTree默认跳过，lxml和DOMParser默认保留；需用节点类型过滤提取，XPath可能受其影响；生产环境建议剥离以避免兼容性和性能问题。
XML解析器默认会保留Comment节点
绝大多数标准XML解析器（如Python的xml.etree.ElementTree、Java的DocumentBuilder、JavaScript的DOMParser）在解析时，<!-- 这是注释 -->会被当作Comment类型的节点保留在DOM树或节点列表中，而不是直接丢弃。这意味着：它不是“被忽略”，而是“被识别为一种合法节点”。
但关键区别在于——不同解析器对它的默认可见性策略不同：
-
ElementTree（Python）默认跳过Comment节点，除非显式调用iterparse并监听'comment'事件，或使用etree.Comment构造器手动插入 -
lxml.etree默认保留Comment节点，可被getchildren()、iter()等方法遍历到（需注意iter(tag=etree.Comment)写法） -
DOMParser（浏览器）把注释作为Node.COMMENT_NODE，childNodes里能拿到，但children（只含Element节点）里没有
如何检测和提取XML中的Comment节点
不能靠肉眼扫，也不能假设getElementsByTagName('*')能捞出注释——它只返回Element节点。必须用支持节点类型过滤的方式。
常见实操方式：
- Python
lxml：[n for n in root.iter() if isinstance(n, etree._Comment)] - Python
minidom：[n for n in doc.childNodes if n.nodeType == Node.COMMENT_NODE] - 浏览器DOM：
Array.from(element.childNodes).filter(n => n.nodeType === Node.COMMENT_NODE) - Java
Document：node.getNodeType() == Node.COMMENT_NODE
注意：ElementTree.parse()不暴露Comment，这是它和lxml最常被踩坑的兼容性差异点。
Comment节点会影响XPath查询结果吗
会影响，但取决于XPath引擎实现和表达式写法。
典型现象：
-
//book/title这类路径不受影响——它只匹配Element节点 -
/root/node()[2]这种按序取节点的表达式，如果第2个节点恰好是Comment，就会命中它（不是报错，而是返回Comment对象） -
child::node()包含Comment；child::element()（XPath 2.0+）则排除它 - 某些老版本
libxml2绑定（如旧版PHPDOMXPath）对comment()轴支持不完整，查//comment()可能返回空
所以，当XPath结果“莫名少了一层”或“索引错位”，先检查中间是否插了注释。
生产环境要不要保留XML注释
大多数API、配置文件、数据交换场景，应该在加载后主动剥离Comment节点。
原因很实际：
- 注释不参与业务逻辑，却占用内存、拖慢序列化/比较速度（尤其大文件）
- 不同解析器处理不一致，导致同一份XML在Python和Java服务中
childNodes.length不等 - JSON转换工具（如
xmltodict）通常默认忽略Comment，若原始XML靠注释传元信息，就容易丢数据 - 安全审计要求日志/缓存中不落开发注释（比如
<!-- TODO: fix auth -->）
剥离示例（lxml）：for c in root.xpath('//comment()'): c.getparent().remove(c)
Comment节点本身没毛病，但它的存在会让“节点序号”“子节点计数”“XPath位置谓词”这些看似简单的东西变得不可靠。真正麻烦的不是它被解析，而是你忘了它被解析了。
