企业官网建设流程全解析

1. 问题场景还原：一次再常见不过的批量删除翻车现场

先交代一下背景。我之前维护过一个基于 Struts2 + Spring + MyBatis 的旧版后台管理系统，里面有个很常规的功能：在用户列表页勾选若干条记录，点“批量删除”按钮，把选中的用户一次性删掉。这个功能从系统上线就存在，某天突然有同事反馈，批量删除偶尔会报错，页面顶部飘出一行红字：Invalid field value for field "ids"。

我的第一反应是“这不可能”，因为这个功能跑了好几年，怎么突然就出问题？后来仔细排查才发现，不是功能本身坏了，而是触发条件变了——以前测试数据都是合法 ID，这次业务部门导入了一批用户，某些用户的主键被配成了特殊值，前端 checkbox 提交的参数内容就变了样，类型转换当场炸掉。

这不是一个冷门 bug，恰恰相反，任何用 Struts2 做过批量操作的人都大概率遇到过。它的表象很简单：页面提交的某个字段值，转换不成 Action 里对应属性的 Java 类型，Struts2 就甩出这句经典的错误提示。但真正的坑在于——同一个错误信息背后，可能藏着七八种完全不同的诱因，如果不把机制搞明白，就只能到处瞎试。

先说我当时复现问题的最小场景。页面长这样：

<form action="user/batchDelete.action" method="post"> <table> <c:forEach items="${userList}" var="user"> <tr> <td> <input type="checkbox" name="ids" value="${user.id}" /> </td> <td>${user.username}</td> </tr> </c:forEach> </table> <button type="submit">批量删除</button> </form>

Action 这边很朴素：

public class UserAction extends ActionSupport { private Long[] ids; private UserService userService; public String batchDelete() { if (ids != null && ids.length > 0) { userService.batchDeleteByIds(ids); } return SUCCESS; } public Long[] getIds() { return ids; } public void setIds(Long[] ids) { this.ids = ids; } }

看起来人畜无害对吧？name="ids"对应Long[] ids，Struts2 会自动把 request 里的多个同名参数封装成 Long 数组。问题就藏在“自动封装”这四个字里。当页面提交的某个 checkbox 值是“”空字符串时，Struts2 要把""转换成 Long，底层Long.valueOf("")直接抛NumberFormatException，于是类型转换失败，错误信息挂到 fieldErrors 上，控制台和页面同时给出Invalid field value for field "ids"。

这类问题的高发场景集中在三类：

• checkbox 全不勾选直接提交。这是最容易踩的坑。很多人以为全不勾选时后端拿到的是 null 或者空数组，但某些浏览器环境下 Struts2 会拿到一个空字符串参数，转换照样炸。
• 数据源本身混入了脏数据。比如从 Excel 导入用户时，编号列混进了非数字字符，前端把它渲染成 value，提交后转换失败。
• 批量提交时关联字段意外带入了多余参数。比如有开发者在 checkbox 旁边又放了一个同 name 的 hidden 域用于兼容旧逻辑，结果两个值拼接成一个参数提交，格式错乱。

这个报错之所以讨厌，不是因为它难修，而是因为它很容易让新手误以为“是数据传参的问题”，但实际上 Struts2 的 ConversionError 拦截机制在里面起了很大作用。下面从机制层面把它彻底讲透。

2. 错误机制拆解：Struts2 是怎么把参数一步步搞炸的

2.1 参数绑定与类型转换的内幕

Struts2 收到一个请求后，参数处理链条大致是：HttpServletRequest→ParametersInterceptor→OGNL 表达式求值→ 调用 Action 属性的 setter 方法。

其中最关键的一环在ParametersInterceptor。它会遍历 request 里所有的参数，对每个参数调用 OGNL 的setValue，把字符串值设置到 Action 对应属性上。如果目标属性是 String，直接赋值，皆大欢喜；如果是Long[]、Integer、Date这类复杂类型，就需要类型转换器介入。

Struts2 默认采用 OGNL 的TypeConverter体系。当它发现 targetClass 是Long[].class，会先把 request 里同名的所有值收集成一个 String[]，再逐一对数组里的每个元素调用convertValue转成 Long，最后组装成 Long[] 赋给属性。

转换失败时 OGNL 会抛出TypeConversionException，这个异常被 ParametersInterceptor 捕获后转成一个 ActionMessage，塞进ActionContext对应的 FieldErrors 集合里。最终页面上那句Invalid field value for field "ids"就是从这里渲染出来的。

这里有两点容易被忽略：

• 转换失败后Action 的该属性不会被赋值，也就是ids依旧是 null。很多人靠if (ids != null)做空判断，结果发现转换失败后这个分支根本不走。
• 转换失败不会中断请求，后续业务方法照常执行。所以如果你的 batchDelete 方法里直接用了 ids，很可能会因为 ids 为 null 而抛出让人摸不着头脑的 NullPointerException，掩盖真实原因。

2.2 ConversionError 拦截器做了什么

在默认的 struts-default 拦截器栈里，ConversionErrorInterceptor紧跟在ParametersInterceptor后面。它的作用是把转换错误的值放回ValueStack对应属性上，保证页面重新渲染时输入框里还能回显用户刚才填的“坏值”，而不是直接清空。

但问题在于：ConversionErrorInterceptor会把原始字符串值重新 push 到 ValueStack 上。如果 Action 在同一请求里又读取了同名属性，读到的是恢复后的原始值，而不是转换后的 Java 对象。我见过不少人在 batchDelete 方法里既用 ids 做逻辑，又通过getIds()回显，结果行为诡异，就是这个拦截器在背后捣乱。

另外，DevMode 下这个错误会显示得更加“奔放”。如果你在 struts.xml 里配置了<constant name="struts.devMode" value="true" />，页面上不仅会显示出错的字段名，还会把 OGNL 内部异常堆栈直接甩出来。生产环境通常关掉 DevMode，所以拿到手的只有一句干巴巴的Invalid field value for field "xxx"，排错难度直线上升。

2.3 为什么数组和集合类型最容易踩雷

数组和集合的转换复杂在“批量处理”上。单个字段比如id=123转成一个 Long，只要格式不对就报错，逻辑简单。但数组类型要把多个同 name 参数收集起来再逐个转换，中途任何一环出错，整个数组就作废。

更坑人的是 HTML 表单的特性：未勾选的 checkbox 不会提交任何参数。这会导致一个隐蔽的行为——假设你有 5 个 checkbox，勾了 2 个，提交的参数只有两个ids；如果全不勾，就一个ids都没有。Struts2 拿到参数集合里根本没有ids这个 key 时，ids会保持 null；但某些时候，如果页面里残留着一个<input type="hidden" name="ids" value="" />，那么传给转换器的就是一个包含空字符串的单元素数组，Long.valueOf("")直接爆炸。

还有更刁钻的：有些前端框架（比如早期 jQuery 版的某些插件）在批量提交时会自动拼接参数，生成类似ids=1&ids=2&ids=的请求串，最后一个ids=没值，转换器一样炸。

所以这个报错可以总结为一句话：字符串转数字失败，错误被 Struts2 拦截后以 fieldError 形式弹出来。只要 string 参数里出现任何无法被目标类型解析的值，数组和集合就尸骨无存。

3. 核心解决方案：四种途径彻底干翻转换错误

知道了机制，解决办法就清晰了。治本和治标的手段我一起给出来，按推荐程度排序。

3.1 方案一：用 String 数组接收，手动转 Long（最稳）

这个思路最朴素，也最不容易出幺蛾子。Action 不直接声明Long[] ids，而是声明String[] ids接收参数，然后在业务方法里自己做转换和过滤。

public class UserAction extends ActionSupport { private String[] ids; private UserService userService; public String batchDelete() { List<Long> idList = new ArrayList<Long>(); if (ids != null) { for (String idStr : ids) { if (idStr == null || idStr.trim().length() == 0) { continue; } try { idList.add(Long.valueOf(idStr.trim())); } catch (NumberFormatException e) { // 记录非法 ID，但不要影响其他合法 ID 的删除 LOG.warn("非法 ID 被忽略: " + idStr); } } } if (!idList.isEmpty()) { userService.batchDeleteByIds(idList); } else { addActionError("请至少选择一条要删除的记录"); return ERROR; } return SUCCESS; } public String[] getIds() { return ids; } public void setIds(String[] ids) { this.ids = ids; } }

为什么这是最推荐的做法？因为它彻底绕开了 Struts2 的类型转换环节。String 到 String 的转换永远不可能失败，接收参数这一步就不会抛异常。真正的容错逻辑放在业务代码里，你随时可以按需调整：过滤空字符串、记录非法值、统计转换失败数量、或者干脆把非法 ID 当作错误返回。灵活性和可观测性都拉满。

注意：这里的 try-catch 并不是多余的防御代码。Excel 导入、历史数据迁移、接口对接都会带来脏数据，谁也无法保证 ID 永远合法。过滤一个脏数据比让整个批量删除失败强得多。

这种写法还带来了一个额外的好处：日志里能精确记录哪些 ID 是脏数据、被哪个用户什么时间触发的。如果 6 个月后又有人反馈批量删除失败，你翻日志能直接给出“某条数据主键不是数字”的结论，不需要再猜。

3.2 方案二：自定义类型转换器，全局兜底（适合多处复用）

如果你的系统里到处都是Long[]、Integer[]、List<Long>这类集合参数，每次都写 String 接收、手动转换的重复代码，那不如做一个全局的类型转换器，把这些槽点一次性解决。

实现方式是继承StrutsTypeConverter，覆盖convertFromString和convertToString：

public class LongArraySafeConverter extends StrutsTypeConverter { @Override public Object convertFromString(Map context, String[] values, Class toClass) { if (values == null) { return null; } List<Long> result = new ArrayList<Long>(); for (String value : values) { if (value == null || value.trim().length() == 0) { continue; } try { result.add(Long.valueOf(value.trim())); } catch (NumberFormatException e) { // 忽略非法值，记录日志 } } return result.toArray(new Long[0]); } @Override public String convertToString(Map context, Object o) { if (o instanceof Long[]) { return Arrays.toString((Long[]) o); } return o == null ? "" : o.toString(); } }

然后在xwork-conversion.properties或者struts.xml里注册这个转换器：

java.lang.Long[]=com.example.converter.LongArraySafeConverter

或者放在 struts.xml：

<constant name="struts.objectTypeDeterminer" value="tiger" /> <constant name="struts.converter" value="com.example.converter.LongArraySafeConverter" />

这里需要提醒一下：注册到全局后，所有 Long[] 属性的转换都会走这个逻辑。如果某个业务场景需要“非法值必须报错，不能静默忽略”，这个全局转换器反而会掩盖问题。所以这种方案更适合“系统整体对数据宽容度较高”的后台管理类项目，如果你对数据准确性的要求特别高，还是方案一更可控。

3.3 方案三：页面侧配合，用隐藏域聚合 ID（不走寻常路）

有一种思路是在页面端就把数据“洗”干净。不直接提交每个 checkbox 的 name，而是用一个 hidden 域把选中的 ID 拼成以逗号为分隔符的字符串，提交时后端只接收一个字符串，自己拆。

大致思路：

<form action="user/batchDelete.action" method="post" id="batchForm"> <input type="hidden" name="idStr" id="idStr" /> <c:forEach items="${userList}" var="user"> <input type="checkbox" class="userCheckbox" value="${user.id}" /> <span>${user.username}</span> </c:forEach> <button type="button" onclick="collectIds()">批量删除</button> </form> <script type="text/javascript"> function collectIds() { var checked = document.querySelectorAll('.userCheckbox:checked'); var ids = []; for (var i = 0; i < checked.length; i++) { ids.push(checked[i].value); } document.getElementById('idStr').value = ids.join(','); document.getElementById('batchForm').submit(); } </script>

Action 那边只需要一个private String idStr;，在方法里 split 成数组后再做数字校验。这种方式的优势是：所有 checkbox 都不用设置 name，彻底避免 Struts2 对 checkbox 数组参数进行类型转换，而且最终交给后端的就是一个干净的字符串，怎么解析完全由你说了算。

缺点也很明显：需要写 JS，而且如果页面里还有其他组件也依赖这些 checkbox 的 name 做联动，改动范围会变大。适合批量删除这种单一提交目标的操作，不太适合那种需要 checkbox 参数和搜索条件同时提交的复杂列表页。

3.4 方案四：用 Map 接收，顺带解决“批量删除局部失败”的痛点

批量删除还有一个业务层面的难点：如果选中的 100 条数据里有 1 条因为外键约束删不掉，是全部回滚还是跳过继续？如果希望“能删多少删多少”，Map 接收的方式反而更好扩展。

页面 checkbox 的 name 直接写成idMap[1]、idMap[2]这种带 key 的形式，Action 里用Map<Long, Long>接收，key 和 value 都是用户 ID。这种写法的妙处在于：key 是稳定的主键，value 也是主键，但如果你愿意，value 可以改为任意业务编号。删除逻辑里可以针对每个 key 单独做权限校验或外键判断，实现了更细粒度的控制。

private Map<Long, Long> idMap; public String batchDelete() { if (idMap != null && !idMap.isEmpty()) { List<Long> ids = new ArrayList<Long>(idMap.keySet()); userService.batchDeleteByIds(ids); } return SUCCESS; }

但要注意，Map<Long, Long>依然涉及类型转换，空字符串一样会报Invalid field value for field "idMap[3]"，所以后面还是要配合 String 接收或者自定义转换器。这个方案更适合扩展批量操作的业务场景，单纯为了绕开转换错误的话，优先级不如方案一。

4. 实操过程与关键细节：从报错到修复的完整记录

4.1 复现现场与日志定位

我当时的排查流程是这样的，给各位一个可复制的参考。

先在开发环境把页面复现出来，勾选部分数据后提交，控制台能看到类似这样的日志：

ERROR [http-nio-8080-exec-4] o.apache.struts2.interceptor.ParametersInterceptor - ParametersInterceptor detected an unexpected error: java.lang.NumberFormatException: For input string: "" at java.lang.Long.parseLong(Long.java:598) at java.lang.Long.valueOf(Long.java:803) at ognl.OgnlOps.getLongValue(OgnlOps.java:256) ...

有了具体异常栈，基本可以锁定是空字符串转 Long 失败。如果没有开日志，也可以在 Action 里临时加一个addFieldError输出，或者打开 DevMode 看详细错误页。

建议：线上环境不要开 DevMode，但至少在log4j或者logback里把org.apache.struts2.interceptor.ParametersInterceptor的日志级别调到 DEBUG。这个类输出内容很详细，能直接看到是哪个参数、哪个值的转换出了错。

4.2 一个容易被忽略的隐藏坑：CheckboxInterceptor 的干扰

排查过程中我还发现一个容易混淆的地方：Struts2 默认拦截器栈里有个CheckboxInterceptor，它的逻辑是：如果检测到某个 checkbox 对应的参数没有出现在请求中，就会自动把一个false值设置到同名 boolean 属性上。这个机制专治“HTML checkbox 不勾选就不提交”的问题。

但它和我们的Invalid field value有什么关系呢？场景是这样的：如果你的 Action 里同时有一个boolean属性和一个Long[]属性，且它们的 name 前缀相同，比如ids和idsEnabled，CheckboxInterceptor可能会错误地把本应传给Long[] ids的参数处理逻辑混淆到 boolean 属性上，导致转换结果异常。

大多数项目不会这么命名，但我在接手的老代码里确实见过这种近似命名的属性。排查时不要只看报错字段，也要把同名前缀的其他属性一并扫一眼。

4.3 微调后的完整代码

最终我采用的方案是方案一（String 数组接收 + 手动转换），同时补了两个细节：

• 返回错误时区别处理：全部是非法 ID、部分合法但删除失败、不合法 ID 过多等场景给不同提示，方便用户定位。
• 并发重复提交防护：批量删除按钮在提交后立即 disabled，后端再叠加一个 token 校验，防止用户手抖连点两次造成重复删除。

这里的 token 校验，Struts2 里有两种选择：tokenInterceptor和tokenSessionInterceptor。前者校验失败跳转invalid.token结果；后者校验失败后保留第一个请求的结果。批量删除这种幂等性敏感操作，我用的是tokenInterceptor，确保不会产生两次删除请求。

完整的 Action 片段：

public class UserAction extends ActionSupport { private static final Logger LOG = LoggerFactory.getLogger(UserAction.class); private String[] ids; private UserService userService; @Override @Validations( requiredStringArrayField = { @RequiredStringArrayFieldValidator(fieldName = "ids", message = "请至少选择一条记录") } ) public String batchDelete() { List<Long> idList = filterValidIds(); if (idList.isEmpty()) { addActionError("没有合法的删除记录"); return ERROR; } try { int deleted = userService.batchDeleteByIds(idList); addActionMessage("成功删除 " + deleted + " 条记录"); return SUCCESS; } catch (DataIntegrityViolationException e) { addActionError("部分记录存在关联数据，无法删除"); LOG.warn("批量删除违反数据完整性约束, ids={}, error={}", idList, e.getMessage()); return ERROR; } } private List<Long> filterValidIds() { List<Long> result = new ArrayList<Long>(); if (ids != null) { for (String idStr : ids) { if (idStr == null || idStr.trim().length() == 0) { continue; } try { result.add(Long.valueOf(idStr.trim())); } catch (NumberFormatException e) { LOG.warn("无效 ID 被忽略: {}", idStr); } } } return result; } // getter / setter ... }

这个版本上线后，批量删除功能再也没有因为Invalid field value出过问题。

4.4 关于“业务层要防御 SQL 注入”的一个补充提醒

改完转换问题后，审查批量删除语句时也要顺手看一下 SQL 写没写对。常见两种方式：IN子句拼字符串、或者用 MyBatis 的foreach动态 SQL。拼接字符串的写法隐患很大，即使参数经过了数字校验，也建议用预编译写法，避免将来有人把方法改成接收 String 数组后引入注入风险。

MyBatis 里推荐用foreach：

<delete id="batchDeleteByIds"> DELETE FROM sys_user WHERE id IN <foreach collection="list" item="id" open="(" separator="," close=")"> #{id} </foreach> </delete>

这算是个顺手提醒，和 convert 错误没有直接关系，但在批量删除这个场景里，从页面参数到持久层是一整条链路，每一步都得干净。

5. 常见问题与排查技巧实录

5.1 踩坑速查表

我整理了一张表格，把这些年遇到过的Invalid field value触发原因和对应的解决方向列出来，方便各位遇到同类问题时快速定位。

5.2 快速定位的三个技巧

如果报错字段明确，直接把它抄到日志里搜。如果字段不明显，我的做法是这个顺序：

• 看日志里的 NumberFormatException 堆栈。它会指名道姓告诉你是哪个类、哪个属性、哪个值出了问题。
• 看 request 参数的原始内容。用浏览器开发者工具或者抓包工具，确认实际请求里 checkbox 提交了什么值。空字符串、逗号拼接的字符串、带引号的数字，一眼就能分辨出来。
• 看 Action 属性的声明类型和 setter 方法。有时候 setter 方法本身做了多余的类型转换，也会引发这个问题，比如在 setter 里Long.parseLong一个空值。

这三个技巧配合使用，90% 的转换错误五分钟内能定位到源头。

5.3 几个配置项背后的隐藏影响

最后提几个容易被忽略的全局配置，它们在批量操作场景里可能有“牵一发而动全身”的影响。

第一个是struts.conversion.allowNull。这个配置默认是 true，决定字符串转数值时，是否允许空字符串被转为 null。如果把它设成 false，空字符串直接被认为非法，报错更频繁。我见过某些安全规范建议设置成 false 来“增强校验”，结果批量操作开始大面积报这个错误。如果你项目里有这个配置，改成 true 能缓解一部分问题，但它治标不治本，还是推荐用 String 接收的方案。

第二个是struts.devMode。调试时可以开，上线前一定要关。我见过不止一个项目把 DevMode 带到生产环境，结果错误信息把内部 OGNL 表达式和文件路径都暴露到了页面上，安全风险极大。

第三个是拦截器栈的顺序问题。如果你在自己的拦截器栈里把ParametersInterceptor放在了自定义拦截器之后，自定义拦截器里已经读过一次参数，可能影响后面的类型绑定结果。默认struts-default的顺序是安全的，自定义栈时注意不要打乱。

5.4 从我实际项目里摘出来的一个特殊复现案例

有一个非常刁钻的案例我印象深刻：批量删除本身没问题，但列表页有一个“导入用户”的功能，导入模板里有一列“主键ID”，业务人员可能填了“00123”、“1.2345E3”这种值。Excel 读进来的时候数字被格式化成科学计数法，传回页面后 checkbox 的 value 变成了1.2345E3，提交到后端，Long.valueOf("1.2345E3")当然报错。

这个问题暴露出批量删除链路里的一个深层隐患：主键的展示格式和数据真实格式不一致。解决方式不在 Struts2 层，而是导入的时候把 ID 字段严格按字符串读取并校验；但如果没处理好，错误最终就是表现在批量删除的Invalid field value上。所以排查这类问题时，不要只盯着提交页面，也要往上游看看数据是怎么生产出来的。

6. 一些可持续迁移的思路：Struts2 的教训在 Spring MVC 里同样适用

虽然 Struts2 已经是老古董级别的框架，但批量删除的报错机制背后其实藏着一个通用问题：Web 框架的参数绑定，默认行为未必符合你的实际数据状况。Spring MVC 里同样有类似问题——用@RequestParam List<Long> ids接收参数时，如果请求里带了空字符串，一样会在参数解析阶段抛MethodArgumentTypeMismatchException。

Spring MVC 的解法比 Struts2 优雅一些：@InitBinder可以注册自定义编辑器，@ControllerAdvice可以做全局异常处理。核心思路和我在 Struts2 里的方案一本质相同：不要默认框架能优雅处理脏参数，自己写一层容错逻辑才是王道。

另外，批量操作无论是哪个框架，都要考虑一个业务层面的约定：批量删除到底是 fail-fast（一个失败全部失败）还是 fail-tolerant（跳过错误继续删除）。这两种模式对应的参数处理策略截然不同。

• fail-fast：适合账户注销、数据清理等场景，要求操作结果是原子的，参数里任何非法值都要立即终止。
• fail-tolerant：适合后台管理、日志清理等场景，允许跳过非法数据，尽量完成更多有效操作。

我自己的经验是在批量删除接口里默认 fail-tolerant，但把“忽略了多少条非法记录”显式写进返回提示里。这样用户不会觉得系统“默默吞掉了数据”，运维也能从日志里看到比例。

这个思路将来哪怕你从 Struts2 迁到 Spring Boot、Spring Cloud，依然适用。参数过滤的功底是通用的，框架只是工具。

7. 写在最后的实战心得

这个Invalid field value for field "ids"的错误，我前前后后在不同项目里遇到过十几次，从一开始的抓瞎、到处问同事，到后来基本一眼能看出问题根子，中间最大的一个领悟是：Web 框架的参数绑定永远不要过度信任。Struts2 也好，Spring MVC 也好，它们默认帮你做的“字符串转对象”只是一个顺从于语法的便利功能，并不是数据校验器。只要前端可控、数据源不可控，就必须自己兜底。

真正动手修的时候，优先保证线上能快速恢复，用 String 接收 + 手动转换是改动最小、风险最低的路子；有余力再去做自定义转换器、全局拦截、前端聚合这些工程化改造。不要一上来就追求“完美方案”，先把痛点上掉，后面再迭代，这是我处理这类问题的一贯节奏。

最后再送一个细节：批量删除成功后记得刷新列表数据的缓存。如果你们的列表有 Redis 缓存或本地缓存，删除完只清数据库是没用的，用户刷新后看到的还是旧数据，会被误认为“没删掉”而重复操作，进而又触发同样的参数问题。删除动作和缓存清理尽量放在同一个事务边界内，别问我怎么知道的——这个坑我也踩过。

批量操作看着简单，细节里全是魔鬼。希望这篇文字能帮你少折腾几个晚上。