简介：这款XML自动生成工具专为Java开发者设计，通过JDBC连接数据库，将查询结果自动映射为符合业务结构要求的XML文档，有效解决手工编写XML时易出错、效率低的问题。资源包共4个文件，以可执行程序为核心，辅以ini、properties等配置文件以及xml示例文件，整体仅144KB，小巧轻便。已有2352人浏览学习，适合需要批量生成XML、快速搭建数据交换接口或处理配置文件的项目团队，也可用于数据库记录批量导出为XML的接口开发或数据迁移场景。工具内部封装了数据库连接、SQL执行与XML映射的完整流程，使用者只需在配置文件中填写数据源地址、账号密码及输出路径，即可自动生成文档。同时支持自定义根元素、命名空间、编码格式等选项，并对表结构到XML元素的映射逻辑进行了简化，能帮助开发者减少重复劳动，提升数据交付效率。
1. 为什么我需要一个自动生成 XML 的工具：从手写 2000 行配置说起
做数据交换对接时，对方下游系统只认 XML 格式的配置文件，而我们上游数据在关系库里，每次导出都要手动拼 XML。最开始我写了段 JDBC 查询脚本，把结果集循环拼字符串，能跑通，但字段一多、类型一杂，转义、缩进、空值处理全是坑。更难受的是，业务方每周都要微调字段映射规则，改一次代码重新编译一次，翻车概率极高。后来我把这事拆成一个「JDBC 数据源 + XML 模板渲染」的独立小工具，用外部模板代替硬编码，用字段映射表代替散落的 if/else，才彻底把这张「后悔药」吃到嘴。这套思路和源码包我整理成了一份可直接复现的资源，适用人群是：需要把数据库表结构或查询结果转成 XML 报文的工程师，做接口联调、数据迁移、报表导出的人都能直接用。
2. JDBC 数据源到 XML：先定格式，再定连接策略
2.1 XML 结构设计的三个基本原则：根节点、命名空间、层级
自动生成 XML 之前，先得回答一个问题：你生成的 XML 长什么样？因为工具只是把数据库字段塞进 XML 骨架里，骨架设计错了，后面全白搭。
我一般会在动手写生成器之前，先用一个样例文件把目标格式定死。常见的设计误区是直接拿数据库表名当根节点，字段名当子节点，结果生成出来的 XML 既没有命名空间，也没有版本信息，对方解析时直接报错。
设计时守住三条原则：
第一，根节点语义必须贴近业务报文，而不是数据库表名。比如数据库表叫t_order_detail，但报文根节点应该叫<OrderInfo>或<OrderRequest>，中间加一层映射关系，让 XML 的语义与业务对齐。
第二，命名空间（xmlns）在第一次设计时就要加上。很多自研系统不校验命名空间，但对接第三方平台时，xmlns:xsi和xsd引用几乎是硬性要求。后补命名空间是所有兼容性修改里最痛苦的，因为所有子节点路径都变了。
第三，层级深度控制在三层以内。数据库表是扁平的，但 XML 往往需要嵌套结构。比如订单主表和订单明细表是两张表，生成 XML 时通常要合并成<Order>下挂多个<Item>的结构。嵌套超过三层，XPath 定位和 Schema 校验的复杂度会指数级上升。
下面是我最终敲定的一份最小样例，作为整个生成器的「契约」文件：
<?xml version="1.0" encoding="UTF-8"?> <OrderRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="order_schema.xsd"> <OrderHeader> <OrderId>ORD20240001</OrderId> <OrderDate>2024-06-18</OrderDate> <CustomerName>测试客户</CustomerName> </OrderHeader> <OrderItems> <Item> <Sku>SKU-1001</Sku> <Quantity>2</Quantity> <Price>199.00</Price> </Item> </OrderItems> </OrderRequest>这份配置文件的价值在于：它同时约束了 XML 骨架和字段顺序。生成器只需要按这个骨架填充变量，不需要关心缩进和换行，因为模板引擎会处理。
2.2 JDBC 连接策略：直连、连接池还是 DataSource 托管
确定了 XML 格式，下一步是决定怎么从数据库拿数据。这里有个容易被忽略的选型问题：JDBC 驱动连接、连接池、还是容器托管的 DataSource。
直连最简单，DriverManager.getConnection(url, user, password)三行代码就能跑。但它的缺点也最明显：每次生成都要新建连接，如果数据量大、查询次数多，连接建立的开销会占据整个生成耗时的一半以上。我做压测时直连模式跑 5000 条订单数据，光连接建立就浪费了将近 4 秒。
连接池方案——比如 HikariCP——是更稳妥的选择。它复用了物理连接，生成器每次只需要从池里借连接，用完归还。参数调优时重点是maximumPoolSize和connectionTimeout，前者控制并发上限，后者控制获取连接的等待阈值。
容器托管的 DataSource 适合在应用服务器里跑，通过 JNDI 查找拿到数据源。但这种方案对独立工具不友好，因为工具是命令行启动的，没有容器环境。我的建议是：单机工具用 HikariCP，做嵌入式集成时直接用外部传入的 DataSource 对象，方便测试时替换成 H2 内存库。
用 HikariCP 时的最小配置如下：
HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://localhost:3306/order_db"); config.setUsername("root"); config.setPassword("password"); config.setMaximumPoolSize(10); config.setMinimumIdle(2); config.setConnectionTimeout(30000); config.setIdleTimeout(600000); HikariDataSource dataSource = new HikariDataSource(config);参数说明：maximumPoolSize设 10 是因为批量生成任务一般单线程跑，10 个连接足够应对嵌套查询和并发分页；connectionTimeout设 30 秒是防止数据库短暂重启时快速失败；idleTimeout设 10 分钟是为了避免空闲连接被 MySQL 服务端断开后，客户端还在使用旧连接。
2.3 查询策略：单表直查还是嵌套查询，取决于 XML 嵌套深度
XML 是嵌套结构，数据库是平面表。把平面数据变成嵌套 XML，有两种常见查询策略。
第一种是单表直查后用内存分组。SELECT * FROM order_item WHERE order_id IN (...)，把结果集按 orderId 分组，再拼装到对应的订单节点下。这种方式 SQL 简单，但内存占用随数据量线性增长。5 万条明细一次性查出，JVM 堆内存至少吃掉 200MB。
第二种是 N+1 查询，即先查主表，再循环查子表。这种方式内存占用平稳，但会产生大量小查询，数据库负载高。一般我配合批量查询优化——每次取 500 个订单号，用IN查询明细表，既能避免 N+1，又不会一次性加载全部数据。
实际生成 XML 时我优先用第二种的变体：分页查主表，批量查子表，然后用Map<String, List<Xxx>>做内存关联。这样既控制了内存水位，也减少了数据库的往返次数。这个策略直接影响生成器的整体流程设计，后续第四步会展开讲。
3. 模板引擎与字段映射：把「改代码」变成「改配置」
3.1 占位符语法设计：${}、#{ } 与自定义指令的取舍
XML 模板引擎的核心是占位符替换。选语法时我对比过 Freemarker、Velocity 和自研替换三种方案。
Freemarker 功能最全，支持条件判断、循环、日期格式化，但学习成本高，模板里写逻辑写多了就变成了另一种编程语言。Velocity 类似。自研占位符替换最简单，<OrderId>${orderId}</OrderId>这种格式，代码里只需要一行template.replace("${orderId}", value)，但循环结构处理不了——订单明细一组多行，没法用简单替换实现。
我的选择是折中：自研一个微型模板引擎，只支持三种语法：
${fieldName}：单字段替换，值来自映射后的 Java Bean 属性或 Map 的 key；{#each items}和{#end}：循环块，内部的占位符按集合元素逐一渲染；{#if condition}和{#end}：条件块，控制某字段为空时不输出整个节点。
设计这套语法是为了让业务人员也能看懂模板——不需要会 Java 就能改模板。这里有一个重要的设计原则：模板里不出现任何 Java 类名或方法名，只出现字段名和逻辑指令，这样文档和模板之间才能严格对应。
模板示例：
<OrderRequest> <OrderHeader> <OrderId>${orderId}</OrderId> <OrderDate>${orderDate}</OrderDate> </OrderHeader> <OrderItems> {#each items} <Item> <Sku>${sku}</Sku> <Quantity>${quantity}</Quantity> <Price>${price}</Price> </Item> {#end} </OrderItems> </OrderRequest>占位符语法里有两个细节容易踩坑：第一，${}与 Spring 框架的${}语法冲突，如果模板放在 Spring 配置目录下，可能被容器误解析；第二，{#if}块结束标记必须独立成行，否则正则解析会拿不到匹配块。
3.2 字段映射表：数据库字段 → Java 属性 → XML 节点名的三级映射
占位符拿到 Java 属性值，Java 属性对应数据库字段，数据库字段又要映射为 XML 节点名。三级映射如果不建表，全靠代码硬编码，改动一次就要重新编译一次，这与自动化工具的初衷相违背。
我的做法是引入一个外部映射配置（properties 或 YAML 格式），让数据库字段名和 XML 节点名解耦。
mappings: - tableColumn: ORDER_ID propertyName: orderId xmlNode: OrderId - tableColumn: ORDER_DATE propertyName: orderDate xmlNode: OrderDate - tableColumn: CUSTOMER_NAME propertyName: customerName xmlNode: CustomerName - tableColumn: SKU_CODE propertyName: sku xmlNode: Sku - tableColumn: QTY propertyName: quantity xmlNode: Quantity这套映射表有三个好处：数据库字段改名后只需改映射配置；XML 节点名与业务对齐不必受数据库命名限制；自定义类型转换逻辑直接在映射配置里指定转换器类名，比如converter: com.example.DateToYyyyMMddConverter。
类型转换是字段映射里最容易被低估的部分。数据库里QTY是 DECIMAL(10,2)，但 XML 里业务要求输出整数；数据库里ORDER_DATE是TIMESTAMP，但报文要求yyyy-MM-dd。这些转换不能写死在生成器主流程里，而是应该作为可插拔的转换器挂在映射配置上。工具包里默认提供了日期格式化、去小数、为空兜底三个常用转换器。
3.3 空值处理策略：缺失节点、空标签还是默认值
数据库字段为 NULL 时，XML 应该怎么输出？这个问题新手容易忽略，但对接方往往很在意。
有三种策略：第一，直接输出空标签<OrderId/>；第二，跳过该节点，整个标签不出现；第三，输出默认值，比如<Quantity>0</Quantity>。
三种策略各有适用场景。像订单号这种主键字段，NULL 表示数据异常，应该输出空标签并告警；像备注这类可选字段，NULL 时跳过更干净；像数量这种有业务默认值的字段，填 0 比留空更符合下游解析逻辑。
我的实现是在映射配置里增加一个nullStrategy属性：
- tableColumn: REMARK propertyName: remark xmlNode: Remark nullStrategy: OMIT - tableColumn: QUANTITY propertyName: quantity xmlNode: Quantity nullStrategy: DEFAULT defaultValue: "0"代码解析时，四种策略分别处理：OUTPUT_EMPTY输出空标签；OMIT不渲染；DEFAULT用配置值替代；RAISE_ERROR则直接中断生成并抛出异常，用于强制校验必填字段。这个设计把空值决策从代码逻辑里拿出来，变成了配置项，业务调整不需要动代码。
4. 生成器主流程与批量输出：核心代码拆解与参数调整
4.1 整体流程：加载配置 → 查询分页 → 模板渲染 → 序列化落盘
生成器主流程我拆成四个阶段，每个阶段单独一个类，方便替换和测试。
第一阶段加载配置：读映射表、模板文件、数据源配置，组装成一个GeneratorContext对象。这个阶段失败的典型情况是模板文件编码不对——Windows 下保存的 UTF-8 模板容易被读成乱码，需要在读取时显式指定字符集。
第二阶段查询分页：先查主表总数，再按页大小拉取主表数据，每拉一页就批量查询子表数据。
第三阶段模板渲染：对每一行主表数据，执行模板引擎的替换逻辑，生成一段 XML 字符串。
第四阶段序列化落盘：验证 XML 格式合法性（比如用DocumentBuilderFactory做一次解析），再写入文件。
核心代码如下：
public class XmlGenerator { private final GeneratorContext context; public XmlGenerator(GeneratorContext context) { this.context = context; } public void generate(String outputDir) { // 阶段一：加载模板和映射配置 TemplateLoader templateLoader = new TemplateLoader(context.getTemplatePath()); Template template = templateLoader.load(); // 阶段二：分页查询主表与子表 int pageSize = context.getPageSize(); long total = orderMapper.countByCondition(context.getQueryCondition()); int totalPages = (int) Math.ceil(total / (double) pageSize); for (int page = 1; page <= totalPages; page++) { List<OrderDO> orders = orderMapper.pageQuery(page, pageSize); List<String> orderIds = orders.stream().map(OrderDO::getId).collect(Collectors.toList()); List<OrderItemDO> items = orderItemMapper.batchQueryByOrderIds(orderIds); Map<String, List<OrderItemDO>> itemMap = items.stream() .collect(Collectors.groupingBy(OrderItemDO::getOrderId)); // 阶段三：模板渲染 for (OrderDO order : orders) { Map<String, Object> root = buildDataModel(order, itemMap.get(order.getId())); String xml = template.render(root); // 阶段四：校验并写文件 XmlValidator.validate(xml); writeToFile(outputDir, order.getId(), xml); } } } }这段代码里的关键是pageQuery和batchQueryByOrderIds。分页用的是「先 count 再按页查」，其中 count 查询在大表上有性能问题，但胜在逻辑简单可控。不想 count 的话，可以用前一次查询返回的最大 ID 做游标分页，但 WHERE 条件复杂时容易漏数据。我一般从「数据一致性优先」这个角度出发，坚持使用 count+页码分页，游标分页只在单表按主键 ID 排序时使用。
buildDataModel的作用是把数据库实体转换成模板引擎渲染所需的Map，在这里应用字段映射表和类型转换器。这一步要特别注意 Map 的 key 必须和模板占位符完全一致。
4.2 XML 序列化：字符串拼接还是 DOM 构建，怎么选
模板渲染的结果是字符串，字符串写入 XML 文件时有两个细节：缩进和特殊字符转义。
缩进靠模板本身就够，但如果模板里没有缩进，生成的 XML 全部挤在一行，阅读性极差。处理方式有两种：一是模板里写好换行和空格，二是生成后调用格式化工具二次美化。
特殊字符转义是硬性问题。数据库字段值里如果包含&、<、>、"等字符，直接拼接进 XML 会破坏结构，导致下游解析失败。
public static String escapeXml(String input) { if (input == null) { return ""; } return input.replace("&", "&") .replace("<", "<") .replace(">", ">") .replace("\"", """) .replace("'", "'"); }这段转义代码虽然简单，但顺序很重要：&必须第一个替换，否则会出现二次转义——比如原文里有一个&，如果先替换<，这个&再被转一次变成&amp;，下游拿到数据就错了。
字符串拼接的优点是快，缺点是难以保证结构合法性。另一种方案是先用 DOM 构建 Document 对象，再用 Transformer 序列化输出。DOM 构建的优点是结构天然合法，缺点是内存占用高，5 万行数据就要小心堆溢出。
我的建议是：数据量 1 万行以内用 DOM 方案，结构有保障；数据量超过 10 万行用模板字符串方案，配合分批写入。TransformerFactory设置indent属性时有个玄学问题——某些 JDK 版本下OutputKeys.INDENT设置"yes"不生效，需要同时设置TransformerFactory.setAttribute("indent-number", 4)才生效，而且这属性在不同厂家的 JDK 上表现不一致，所以不要依赖序列化器的缩进，主要靠模板本身控制格式。
4.3 批量输出的文件切分流：按主键范围、按数量还是按时间
生成结果不能全部塞进一个超大 XML 文件时，就需要切分策略。三种常见切法。
按主键范围切分，比如每 5000 个订单一个文件。实现简单，但如果订单量分布不均匀，每个文件大小差异会很大。
按数量切分是最直观的——每 N 行数据一个文件。这个方案在数据量均匀时效果不错，但在明细表行数相差悬殊时问题明显：一个订单有 1000 条明细，另一个订单只有 1 条明细，按明细数量切分会让同一个订单的明细分裂到两个文件，破坏业务完整性。
按时间切分适合有日期字段的报表类数据，比如每小时一个文件。但如果某个小时没有数据，会生成空文件，反而增加下游处理的麻烦。
我最终采用「按主表记录数 + 子表明细完整性」的组合策略：每 1000 个订单主表记录切一个文件，每个文件的子表数据是完整拉取的，不会出现同一订单明细被拆到两个文件的情况。文件命名规则是output_0001.xml、output_0002.xml递增编号，方便下游用通配符读取。
public List<File> splitAndWrite(List<OrderDO> orders, Map<String, List<OrderItemDO>> itemMap) { List<File> files = new ArrayList<>(); int fileIndex = 1; int batchSize = context.getFileBatchSize(); // 1000 for (int i = 0; i < orders.size(); i += batchSize) { List<OrderDO> subOrders = orders.subList(i, Math.min(i + batchSize, orders.size())); Map<String, Object> root = new HashMap<>(); root.put("orders", subOrders); // items 在渲染时通过 orderId 关联 String xml = template.render(root); File f = new File(context.getOutputDir(), "output_" + String.format("%04d", fileIndex++) + ".xml"); FileUtils.writeStringToFile(f, xml, StandardCharsets.UTF_8); files.add(f); } return files; }这里的fileBatchSize不是越小越好。太小会产生大量小文件，下游处理时频繁打开关闭文件；太大又带来单文件超限的风险。1000 到 5000 是我试过比较舒服的范围，具体看对方系统单文件大小限制。
5. 避坑与排查：5 个高频故障的现场还原与修复
5.1 生成的 XML 在对方系统里解析乱码
现象：生成的 XML 文件在本机打开一切正常，但传输到对方服务器后用对方的解析程序读取，中文变乱码，或者直接报「Invalid byte 1 of 1-byte UTF-8 sequence」错误。
原因：问题几乎都出在文件写入时的字符集上。最常见的是用FileWriter默认编码写入，Windows 下默认是 GBK，而 XML 声明里写的是UTF-8，两者不一致。另一种情况是 XML 声明没写encoding="UTF-8"，对方解析器用了系统默认编码读取。
解决：写入时强制指定OutputStreamWriter(fos, StandardCharsets.UTF_8)，同时检查 XML 声明里是否有encoding="UTF-8"。养成一个习惯：生成的 XML 用file命令看一眼编码信息再做传输。
5.2 JDBC 查询超时，数据量一大就中断
现象：从 5 万条订单及 20 万条明细时开始出现QueryTimeoutException，偶尔还会碰到CommunicationsException: Communications link failure。
原因：statement.setQueryTimeout()设太短，或者连接被数据库端主动断开。数据量大时查询耗时本来就长，如果没设 fetchSize，MySQL JDBC 驱动默认一次性拉取全部结果，内存和网络都吃不消。
解决：设置合理的查询超时和fetchSize。setFetchSize(500)可以让游标按批拉取数据，而不是一次性全量传输。另外，连接空闲超过wait_timeout会被 MySQL 断开，需要连接池的idleTimeout小于 MySQL 的wait_timeout，我一般设 10 分钟，正好低于常用的 8 小时默认值。
5.3 模板里的循环块没生效，明细全没输出
现象：模板里写了{#each items}，但生成的结果里<OrderItems>标签下是空的，一个<Item>都没有，主表字段倒是正常输出了。
原因：buildDataModel返回的 Map 里 key 是"orderItems"而不是"items"，或者 item 列表压根没被塞进 Map。模板引擎按items查找集合数据，找不到就直接跳过循环块，又不报错，排查起来特别隐蔽。
解决：在buildDataModel中打印 key 集合和值类型，确认 key 与模板占位符完全一致。模板引擎做循环前判断数据是否为Collection或数组，不是就抛出异常，不能静默跳过。我把这个报错行为改成了「严格模式」，宁可让生成失败也不产出残缺数据。
5.4 特殊字符导致 XML 结构被破坏，标签凭空消失
现象：某个订单的客户名称里有&符号，比如「AT&T 科技」，生成的 XML 中这个字段后面的标签全乱了，下游解析直接抛XML document structures must start and end within the same entity。
原因：字段值未做转义就直接拼进了模板，&被 XML 解析器当作实体起始符。
解决：模板渲染对每个字段值做escapeXml转义。顺时针顺序是固定的，先&再<>，顺序不能乱。如果发现字段值里混有&，说明前面已经转义过一次，再转义时要判断是否重复转义——一个实用的做法是在工具里加一个「已转义」标记位字段，不渲染时不做二次转义。
5.5 映射配置改了没生效：配置文件缓存问题
现象：修改了 YAML 映射表，重新运行生成器，但字段映射结果还是旧版，像是改动没被读取。
原因：生成器启动了配置缓存。如果程序是常驻内存的服务，第一次加载时把映射表存到了静态 Map 里，后续重跑都用缓存副本。或者是 YAML 文件被 IDE 自动编译到了 target 目录，改的是源码目录下的文件，程序读的是编译产物。
解决：工具启动时不启用配置缓存，每次运行都强制重新读取映射文件；同时检查当前运行目录下是否有多份同名配置副本，用-Dconfig.path=/abs/path/xxx.yml指定绝对路径，排除读到旧文件的可能。从那以后我每次改完映射配置，都会先在命令行里跑一条diff对比实际读取的配置文件和最新修改的文件，确认一致再跑全量生成。
6. 进阶验证：用 XML Schema 校验加增量生成，让自动化真正可信
XML 生成器跑出来的文件格式对不对，不能只靠自己眼睛看。我最后加了两个层面的验证：外部 XSD Schema 校验和内部结构化比对。
XSD 校验的做法是：下游如果提供 XSD 文件，直接用javax.xml.validation加载 Schema 后校验生成的 XML 文件。我把这个校验嵌到了生成流程里，每生成一个文件就校验一次，校验失败则立即停止生成并打印文件和原因。不要等到全部生成完再统一校验——数据量大的时候，等到最后一个文件才发现第一个文件有问题，日志会被埋得很深。
public static void validateXmlByXsd(String xmlPath, String xsdPath) throws SAXException, IOException, ParserConfigurationException { SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); Schema schema = factory.newSchema(new File(xsdPath)); Validator validator = schema.newValidator(); DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); Document doc = dbf.newDocumentBuilder().parse(new File(xmlPath)); validator.validate(new DOMSource(doc)); }这段代码的要点是setNamespaceAware(true)，如果为 false，带命名空间的 XML 会被误判成「找不到元素声明」。另外SchemaFactory加载 XSD 时如果 XSD 引用了别的 XSD 文件，需要配置LSResourceResolver，否则会报找不到导入文件。
结构化比对则针对没有 XSD 的场景：对每一份生成的 XML，解析成 DOM 树，统计节点路径和节点值的分布，与上一批生成结果做 diff。这个方案能快速发现字段错位、数值精度变化、节点缺失问题。实现原理是把 DOM 树转换成规范化的字符串——所有空白节点统一删除，属性顺序按字典序排列，再做字符串比较。
增量生成是另一个实用进阶功能。业务方经常说「不要全量重新生成，只要补上一次生成之后新增的记录」。实现思路：在订单表里增加一个LAST_GENERATED_TIME字段，每次生成完成后把本次处理的MAX(ORDER_DATE)回写到元数据表，下次生成时WHERE ORDER_DATE > 上次记录值。这个方案依赖数据库时间字段的单调性，时间倒灌会让数据丢失，所以我在工具里加了一个校验——如果本次查询到的最大时间小于上次记录的时间，直接告警而不是静默跳过。
做增量生成时，模板、映射表、输出目录这些配置要和全量生成完全隔离，避免误覆盖。我在配置结构里用generateMode: FULL和generateMode: INCREMENTAL区分两者。
最后说一个我踩过最深的坑。第一次做全量生成时，我发现生成的 XML 总量比预估的小了很多。排查后确认是分页查询时ORDER BY没加主键，MySQL 分页结果不稳定，导致某些订单在两次分页中没有被返回，直接漏数据了。从那以后，我每次写分页查询都强制要求排序字段必须唯一，哪怕是主键加一个非唯一字段的联合排序，也一定不能裸分页。希望能帮到你，让这套 XML 自动生成工具在你的场景里少走这些弯路。
本文还有配套的精品资源，点击获取
