Redis 能存 XML 但不推荐直接存原始字符串，应先校验格式、过滤恶意内容并压缩；更优方案是解析后按结构存入 HASH、LIST 等类型，拆分字段并设置独立 TTL，配合事件驱动失效，确保缓存一致性。
Redis 能存 XML，但别直接当字符串塞进去
能存，但不推荐把整个 XML 字符串原样塞进 Redis 的 SET 或 STRING 类型里。XML 是结构化文本，自带嵌套、命名空间、属性和缩进，Redis 本身不解析它，也不校验格式——你存进去什么，取出来就是什么，错一个 </tag> 都得自己 debug。
常见错误现象：XML parse error: mismatched tag，结果查半天发现是缓存里混进了未闭合的 <item>，或者换行符被截断导致格式损坏。
- 用
SET存原始 XML 前，务必先做XML格式校验（比如用DOMParser或xml.etree.ElementTree尝试解析） - 如果 XML 来自不可信输入（如用户上传、第三方 API），必须做转义或白名单过滤，避免注入恶意实体（如
&xxe;） - 考虑压缩：大 XML（>10KB）建议用
gzip压缩后再存，Redis 不内置压缩，得在应用层处理
更合理的做法：解析后存结构化数据
XML 的价值在结构，不是文本。与其缓存一整坨字符串，不如解析成键值对或对象，再按需拆到 Redis 不同类型里——这样能查、能过期、能更新局部字段。
使用场景：比如缓存一份配置 XML：<config><timeout>30</timeout><retry>3</retry></config>
- 存成
HASH：用HSET config:123 timeout 30 retry 3，后续可单独改retry而不用重刷整个 XML - 列表类 XML（如
<items><item id="1">A</item><item id="2">B</item></items>）适合转成LIST或SET，用LPUSH config:123:items "A" "B" - 带层级的（如多级菜单 XML），可扁平化为带分隔符的 key：
menu:home:children、menu:home:icon
注意命名空间和特殊字符的坑
XML 里的 xmlns、xml:lang、 这类东西，解析时容易被忽略，但存进 Redis 后若没统一编码/转义，取出来可能乱码或解析失败。
- 所有 XML 内容入库前，强制用
UTF-8编码，Redis 默认不处理编码，靠客户端保证 - 属性值含双引号或单引号？用
xml.sax.saxutils.escape()（Python）或encodeURIComponent()（JS）预处理，否则可能破坏 JSON 包装或命令拼接 - 不要依赖 Redis 的
GET返回值直接喂给 XML 解析器——先检查是否为空、是否超长（STRLEN）、是否含非法控制字符（如\x00）
缓存失效和一致性怎么搞
XML 数据一旦变更，缓存就得同步失效。但 XML 很少整体替换，更多是字段级更新，硬清整个 key 容易引发缓存雪崩或脏读。
- 给每个 XML 拆出的子项加独立 TTL，比如
config:123:timeout过期时间设为 5 分钟，config:123:retry设为 1 小时 - 用
PUB/SUB或业务事件驱动失效：上游服务改完 XML 后，发一条PUBLISH xml:update:123 "timeout"，监听端删对应字段 - 避免用
KEYS *扫描 XML 相关 key——性能差还阻塞，改用带前缀的SCAN，比如SCAN 0 MATCH config:123:* COUNT 100
真正麻烦的是 XML 和数据库双写场景：DB 更新成功了，Redis 却写挂了。这时候要么加补偿任务，要么干脆放弃强一致，接受几秒延迟——毕竟 XML 缓存本就不是为事务设计的。
