XMLEventReader 的 next() 抛 NoSuchElementException 是因未做空检查，需确保 hasNext() 为 true 后再调用；取属性值须先类型校验再强转并调 getValue()；解析大文件时禁用事件缓存和过度 peek，开启命名空间支持并正确管理上下文。
为什么 XMLEventReader 的 next() 会抛 NoSuchElementException
因为 next() 不做空检查，它假定你已确认还有事件可读——这和 Iterator 的契约一致，但容易在循环末尾误用。常见错误是写成 while (reader.hasNext()) { event = reader.next(); ... } 后，又多调一次 next()（比如想 peek 下一个），结果越界。
- 正确姿势：只用
hasNext()+next()配对，且每次next()前必须确保hasNext()返回true - 安全替代：改用
nextEvent()（返回当前事件并移动）或peek()（只看不移动），它们在流末尾返回null，不抛异常 - 注意：
next()和remove()都是Iterator接口方法，但 StAX 实现中remove()总是抛UnsupportedOperationException，别碰
XMLEventReader 读到 START_ELEMENT 后怎么取属性值
不能直接 cast 成 StartElement 就完事——得先确认类型，再用 getAttributeByName() 或遍历 getAttributes()。很多代码漏掉类型检查，导致 ClassCastException。
- 必须先
if (event.getEventType() == XMLStreamConstants.START_ELEMENT)，再强转 - 获取单个属性用
((StartElement) event).getAttributeByName(new QName("id"))，注意QName构造：无命名空间传null作前缀，否则可能匹配失败 - 遍历所有属性推荐用
asCursor().forEachRemaining(...)或传统 for-each +getAttributes()，避免反复 cast - 属性值是
Attribute对象，要调getValue()才拿到字符串，不是toString()
用 XMLEventReader 解析大文件时内存暴增怎么办
StAX 本身是拉模式、低内存，但常见滥用会让它退化成 DOM：比如把所有 XMLEvent 缓存进 List，或反复调 peek() 导致内部缓冲膨胀。
- 绝对不要用
new ArrayList()收集全部事件——事件对象带位置信息和引用，累积后 GC 压力大 -
peek()调用次数越多，底层预读缓冲越深；生产环境应限制 peek 深度（比如最多 peek 2 层），或改用nextTag()跳过无关内容 - 确保
XMLInputFactory设置了IS_COALESCING为false（默认 false），设为 true 会合并相邻文本节点，反而增加临时对象 - 关闭流后记得调
reader.remove()？不用——remove()不生效，真正要的是reader.close()，否则解析器资源不释放
如何让 XMLEventReader 正确处理命名空间和前缀绑定
默认情况下，START_ELEMENT 的 getNamespaceContext() 返回的上下文可能为空或不完整，导致 getAttributeByName(new QName("ns", "val")) 匹配失败。
立即学习“Java免费学习笔记（深入）”；
- 创建
XMLInputFactory后，必须显式开启命名空间支持：factory.setProperty(XMLInputFactory.IS_NAMESPACE_AWARE, true) - 在循环中遇到
START_ELEMENT时，用((StartElement) event).getNamespaces()获取本元素声明的前缀绑定，但注意它只返回「新增」绑定，不包含外层继承的 - 如需完整上下文，应维护一个栈式
NamespaceContext实现，或改用XMLStreamReader的getNamespaceURI(String prefix)（更稳定） - 测试时用带
xmlns:ns="http://example.com"的 XML，别只用无命名空间的样例——后者掩盖问题
