MuleSoft Anypoint 平台通过 File Connector 的 file:listener 监听指定目录（如 /opt/inbound）中匹配 *.xml 的文件，需配置 polling-frequency、moveToDirectory 避免重复处理，并用 xml-to-object 解析为可用对象，同时注意路径权限、部署环境差异及文件锁定问题。
MuleSoft Anypoint 平台本身不直接“接收 XML 文件”——它靠 File Connector（文件连接器）监听本地或网络路径，读取文件内容；XML 的解析、路由、验证等后续动作，需你显式配置（比如用 xml-to-object 或 validate-xml-schema）。File Connector 只负责“把文件拿进来”，不管里面是不是 XML，也不自动做 schema 校验。
File Connector 怎么监听入站 XML 文件？
核心是配置一个 file:listener，它会轮询指定目录，发现匹配 filename-pattern 的文件就触发流程。XML 文件只是普通文件，所以重点在路径、模式和触发时机：
- 必须指定
directory（绝对路径，如/opt/inbound），Mule 运行用户需有读+执行权限（否则看不到子目录） -
filename-pattern推荐设为*.xml，但注意：它不递归子目录，如要监听/inbound/xml/，就得写死这个路径，不能只写/inbound - 默认每 500ms 轮询一次，高频小文件易漏读；生产建议调到
1000–5000ms，并开启moveToDirectory避免重复处理 - 文件被成功处理后，务必用
file:move移走或重命名，否则下一轮又会触发——这是最常被忽略的坑
<file:listener config-ref="File_Config"
directory="/opt/inbound"
filename-pattern="*.xml"
moveToDirectory="/opt/processed"
polling-frequency="2000"/>拿到 XML 后怎么解析成可用数据？
File Connector 输出的是 byte[] 或 InputStream，不是 Java 对象。必须显式转换，否则后续无法用 DataWeave 按字段引用（比如 payload.name 会报错）：
- 用
xml-to-object（推荐）：将 XML 转为 Map/List 结构，支持嵌套、属性、命名空间，兼容性好 - 避免用
parse xml（旧版 DataWeave 表达式），它不校验格式，遇到 malformed XML 会静默失败 - 如果 XML 有 XSD，加一步
validate-xml-schema：传入schemaLocation（如classpath://mt103.xsd），校验失败会抛VALIDATION:XML_SCHEMA_VALIDATION_ERROR - 注意命名空间：若 XML 带
xmlns="http://schemas.xxx"，DataWeave 中必须用ns0:name引用，且需在脚本顶部声明%namespace ns0 "http://schemas.xxx"
为什么文件没被读取？常见卡点排查
不是配置写错，而是环境/权限/语义细节导致“静默失败”：
-
directory路径在本地开发时用C:/in没问题，但部署到 CloudHub 或 Runtime Fabric 时，该路径根本不存在——必须改用挂载卷或对象存储（如 AWS S3 + S3 Connector） - Linux 上路径末尾带斜杠（
/opt/inbound/）可能被某些 Mule 版本截断，导致实际监听/opt/inbound目录不存在，建议统一去掉末尾/ - 文件正在被其他进程写入（如 FTP 上传中），File Connector 默认会跳过“正在写”的文件；可启用
prevent-file-locking="true"（仅限 4.4+），但会增加 I/O 开销 - 日志里出现
Could not list files in directory：90% 是权限问题——检查ls -ld /opt/inbound，确认运行 Mule 的用户（如mule）有r-x权限
真正麻烦的从来不是“怎么配”，而是“为什么它不干活”。File Connector 看似简单，但路径、权限、文件状态、部署环境这四层，漏掉一层就卡住。尤其上线前别只测本地，一定要在目标环境跑一次真实文件流。
