Could not set property 'pkCheckInfos' of 'class com.ruoyi.safemass.domain.TtCheckInfo' with value '1110003810' Cause: java.lang.IllegalArgumentException: argument type mismatch

<think>嗯，用户遇到了一个MyBatis的反射异常，具体是设置属性'pkCheckInfos'时参数类型不匹配。我需要帮他分析可能的原因和解决办法。首先，我得回顾一下类似的错误案例。根据提供的引用[1]、[2]、[3]、[4]、[5]，这类错误通常和类型转换或主键生成策略有关。 首先，可能的原因之一是实体类属性类型与数据库字段类型不匹配。比如，数据库中的字段可能是varchar，而实体类里用的是Long或者Integer，或者反过来。这时候MyBatis在映射的时候就会抛出类型不匹配的错误。比如引用[3]中的例子，createTime的值是时间戳字符串，但实体类可能用了Date类型，导致转换失败。所以需要检查TtCheckInfo类的pkCheckInfos属性的类型，以及对应的数据库字段类型是否一致。 其次，可能是MyBatis的TypeHandler配置问题。如果属性类型是自定义对象或者复杂类型，可能需要配置自定义的TypeHandler来处理数据库字段到Java对象的转换。如果没配置或者配置错误，也会导致类型不匹配。例如，如果pkCheckInfos是一个对象，但数据库字段是字符串，可能需要JSON转换的TypeHandler，如引用[5]提到的JSON字段处理。 另外，主键生成策略错误也是一个可能性。比如，数据库使用自增主键，但实体类配置了错误的生成策略，导致传入的值类型不符合预期。引用[4]和[5]提到，如果主键生成策略配置错误，比如用ASSIGN_ID生成Long类型，但数据库是varchar，就会出错。需要检查@TableId注解的type是否正确，或者是否应该使用其他策略如ASSIGN_UUID。 还有可能是MyBatis-Plus的自动填充功能配置错误。比如，字段自动填充的处理器返回类型和属性类型不一致，导致设置值时类型不匹配。需要检查是否有MetaObjectHandler的配置，特别是针对pkCheckInfos字段的处理是否正确。 最后，数据源的问题也不能忽视。比如，数据库返回的值类型与实体类属性类型不符，可能是在SQL查询中进行了类型转换，但结果类型不匹配。需要检查Mapper XML中的resultMap配置是否正确，是否有类型转换器被错误应用。 总结下来，解决步骤应该是： 1. 检查实体类和数据库字段类型是否匹配。 2. 确认TypeHandler是否正确配置，特别是复杂类型。 3. 检查主键生成策略是否正确。 4. 审查自动填充配置。 5. 查看Mapper XML中的类型映射。 6. 通过日志或调试确认实际传入值的类型。 用户需要逐一排查这些可能性，尤其是先从类型匹配和TypeHandler入手，因为这些是最常见的问题点。另外，查看错误堆栈中的具体行号也能帮助定位问题所在，比如是哪个字段在设置时出错，从而更有针对性地检查相关代码。</think>### 问题分析：`java.lang.IllegalArgumentException: argument type mismatch` 设置属性 'pkCheckInfos' 时的类型不匹配问题 #### 可能原因及解决方案： 1. **实体类属性类型与数据库/参数类型不匹配** - **现象**：尝试将数据库字段或传入参数的值赋给 `TtCheckInfo` 类的 `pkCheckInfos` 属性时，类型无法自动转换。 - **验证方法**： - 检查 `TtCheckInfo` 类中 `pkCheckInfos` 属性的数据类型（如 `List`、`String` 或自定义对象）。 - 核对数据库表中对应字段的类型（如 `VARCHAR`、`BLOB` 或关联表的主键类型）。 - 若使用 MyBatis-Plus 自动填充字段，检查 `@TableField` 注解的 `typeHandler` 配置（例如 JSON 转换需使用 `JacksonTypeHandler`）[^5]。 2. **主键生成策略错误** - **场景**：若 `pkCheckInfos` 是主键字段，且使用了 MyBatis-Plus 的主键生成策略（如 `ASSIGN_ID`、`INPUT`）。 - **解决方案**： - 确认 `@TableId` 注解的 `type` 属性是否与数据库主键类型匹配（例如：`IdType.ASSIGN_ID` 对应 `Long` 类型，`IdType.ASSIGN_UUID` 对应 `String` 类型）[^4][^5]。 - 若主键为联合主键，需使用 `@TableId` 结合复合主键配置。 3. **类型处理器（TypeHandler）缺失或配置错误** - **案例**：若 `pkCheckInfos` 是复杂对象（如 `List<CheckInfo>`），需在字段上指定类型处理器： ```java @TableField(typeHandler = JacksonTypeHandler.class) private List<CheckInfo> pkCheckInfos; ``` - **数据库字段**：对应字段需存储 JSON 字符串（如 `VARCHAR` 或 `TEXT`）。 4. **自动填充功能配置问题** - **排查点**：若 `pkCheckInfos` 字段配置了 `@TableField(fill = FieldFill.INSERT)`，需检查 `MetaObjectHandler` 的实现类中填充值的类型是否与属性一致[^3]。 5. **Mapper XML 文件中的类型映射错误** - **检查项**：在 `resultMap` 或动态 SQL 中，确保 `property="pkCheckInfos"` 的 `jdbcType` 与数据库一致（例如 `jdbcType="VARCHAR"`）。 --- ### 操作步骤： 1. **检查实体类与数据库字段类型一致性** 对比 `TtCheckInfo` 类中 `pkCheckInfos` 的 Java 类型和数据库字段类型。 **示例**： - 若数据库存储 JSON 字符串，实体类属性应为 `List` 类型并配置 `JacksonTypeHandler`。 2. **调试日志定位具体赋值位置** 在日志中搜索 `Setting property 'pkCheckInfos'`，查看赋值时的值类型（如数字 `123` 尝试赋给 `String` 类型）。 3. **验证主键生成策略** 若涉及主键生成，检查 `@TableId` 注解的 `type` 值是否符合数据库要求： ```java @TableId(type = IdType.ASSIGN_ID) // 适用于 Long 类型主键 private String pkCheckInfos; // 类型不匹配会引发异常 ``` 4. **显式配置类型处理器** 在字段上强制指定类型处理器： ```java @TableField(value = "pk_check_infos", typeHandler = JacksonTypeHandler.class) private List<CheckInfo> pkCheckInfos; ``` --- ### 相关引用 - 类型不匹配常见于字段类型与数据库不兼容（如时间戳与字符串）。 - 主键策略错误会导致赋值类型冲突（如 `Long` 类型赋给 `String` 字段）[^4]。 --- §§ 1. MyBatis-Plus 如何配置联合主键？ 2. 如何自定义 MyBatis 类型处理器处理 JSON 字段？ 3. MyBatis-Plus 的主键生成策略有哪些区别？