xs:element 的 fixed 属性仅锁定该元素在实例中出现时的值，不约束类型、存在性或子结构；若元素未出现则校验通过，出现则值必须严格匹配。
xs:element 的 fixed 属性到底锁住了什么
它只锁住该元素**在实例文档中出现时的值**，不锁类型、不锁是否出现、不锁子内容结构。哪怕你声明了 fixed="true"，只要这个元素根本没出现在 XML 实例里，校验照样通过。
常见错误现象：XMLSchemaValidationError 提示“value does not match fixed value”，其实只是因为元素出现了，但值不对；反过来，删掉整个元素反而能过校验——很多人误以为 fixed 是强制存在 + 强制值，其实它只管“如果存在，就必须是这个值”。
-
fixed和default互斥：同一个xs:element不能同时指定两者 - 如果元素是可选的（
minOccurs="0"），fixed不会改变它的可选性 - 当元素是复杂类型时，
fixed仅适用于简单内容（即不能给一个带子元素的xs:element设fixed值）
用 fixed 还是用 default？看场景
想让解析器自动补值，用 default；想在验证时卡死某个字段的取值范围，用 fixed。比如 API 协议中要求 <version>2.1</version> 必须写死，就不能依赖默认值，否则客户端漏写也能蒙混过关。
- 客户端生成 XML 时，
default值由序列化库自动注入（如 JAXB 的@XmlDefaultValue）；fixed值则必须显式写出，否则校验失败 - 某些 XSD 工具（如 xsd.exe）对
fixed支持不一致，生成的类可能忽略该约束，导致运行时无感知 - 在 WSDL 绑定中，
fixed值不会参与 SOAP 消息的动态计算，它是个静态断言
fixed 遇到类型转换容易翻车
如果你给一个 xs:decimal 类型的元素设 fixed="3.14"，那实例里写 <pi>3.140</pi> 就可能失败——XSD 的相等判断是按值语义，不是字符串匹配，但某些处理器（尤其是老版本 MSXML 或早期 libxml2）会做松散比较，行为不统一。
- 整数字面量慎用：写
fixed="42"比fixed="42.0"更安全，避免浮点表示歧义 - 枚举类型上加
fixed很常见，但要注意xs:enumeration的value是字符串，fixed值必须完全匹配那个字符串字面量 - 使用
xs:pattern限制后，再加fixed是冗余的，校验器通常只认fixed，pattern被跳过
验证时 fixed 约束被绕过的典型路径
很多开发者调试半天发现 fixed 没生效，其实是校验流程本身没走全。最常见的是：用 DOM 解析器加载 XML 后手动遍历节点，压根没调用 SchemaFactory 或 setSchema()；或者用了 DTD 校验模式，XSD 的 fixed 完全不参与。
- Java 中用
SAXParserFactory.setSchema()才会触发fixed检查；DocumentBuilder默认不校验 XSD 约束 - Python 的
lxml.etree.XMLSchema必须显式调用.validate()，光 parse 不校验 - Postman 或 curl 发送 XML 时，服务端若只做基础解析（如 Python 的
ElementTree.fromstring()），fixed纯属摆设
真正难缠的不是语法怎么写，而是得确认整个工具链从 XSD 编译、实例生成、传输、到服务端解析校验，每个环节都明确支持并启用了 fixed 语义——漏掉一环，它就静默失效。
