MyBatis商品库存管理实战教程

本文聚焦Java实战中MyBatis在控制台商品库存管理系统开发时的四大关键陷阱：合理选用selectOne与selectList以避免空指针或异常崩溃、统一用nextLine()配合手动类型转换解决Scanner输入缓存干扰、严格校验UPDATE/DELETE语句的WHERE条件和参数名一致性防止全表误更新、正确处理MySQL tinyint(1)到Java布尔值的映射问题规避反序列化错误；每一条都是生产环境中极易被忽视却可能导致数据静默错乱的“安静炸弹”，尤其在无UI校验的命令行场景下，稍有松懈便酿成严重后果。

MyBatis 的 selectOne 和 selectList 到底该用哪个？

查库存时返回 0 条或 1 条记录，用 selectOne 看似合理，但一查不到就抛 org.apache.ibatis.exceptions.TooManyResultsException 或返回 null，反而让业务逻辑变脆弱。

• 查单条且**必须存在**（比如根据主键查商品），用 selectOne；否则优先用 selectList + 取 get(0) 或判空
• selectOne 遇到多行结果直接炸，不给你兜底机会；selectList 始终返回 List，可控性强
• MyBatis 3.4+ 对 selectOne 的 null 处理更保守——即使 SQL 查不到，也只返回 null，不会自动转成空对象

控制台输入数字却读成字符串，导致 SQL 查询失败

用 Scanner.nextInt() 读商品 ID 后紧接 nextLine() 读名称，第二步总会拿到空字符串——因为 nextInt() 不吞回车符，残留的 \n 被 nextLine() 当成有效输入了。

• 统一用 nextLine() 读所有输入，再用 Integer.parseInt() 转数字，避免缓存干扰
• 转数字时必须包 try-catch，用户输 “abc” 会崩在 NumberFormatException，别等 MyBatis 报错才处理
• 数据库字段是 INT，但 Java 里用 Integer 接收，别用 int——空值时会默认成 0，掩盖真实问题

更新库存时没加 WHERE 条件，全表数据被刷成一样

写 updateStock 方法时，XML 里漏写 where id = #{id}，或者传参时 id 字段名拼错（比如写成 productId 但 POJO 里叫 id），MyBatis 就真会执行 UPDATE product SET stock = ?——整张表库存全变。

• 所有 UPDATE / DELETE 语句，先检查 XML 或注解中是否有明确的 WHERE 子句，再核对参数名和 POJO 字段名是否完全一致
• 开发阶段在 MyBatis 配置里打开 logImpl="STDOUT_LOGGING"，眼见为实看生成的 SQL 长什么样
• 测试时故意用不存在的 id 更新一次，确认影响行数是 0；否则上线后才发现，已经晚了

MySQL 的 tinyint(1) 映射成 Java 的 Boolean 总出错

库存为 0 时显示“缺货”，前端常靠布尔值判断，但 MySQL 里用 tinyint(1) 存状态，MyBatis 默认映射成 Integer，不是 Boolean。硬写 boolean inStock 字段会导致反序列化失败或值错乱。

• 要么改数据库字段类型为 BIT 或 BOOLEAN（MySQL 实际还是 TINYINT），并配 typeHandler="org.apache.ibatis.type.BooleanTypeHandler"
• 要么 Java 侧保持 Integer 字段，用 inStock != null && inStock > 0 判断，更直白、无隐式转换风险
• 别信某些博客说“加 @Column 就能自动转”，JDBC 驱动层不认这个注解，MyBatis 也不处理

库存管理看着简单，但 MyBatis 的参数绑定、SQL 拼接时机、JDBC 类型映射这三块，任何一个环节松一点，数据就可能静默错乱——尤其在控制台这种没有 UI 校验的场景下，错得越安静，修得越费劲。

终于介绍完啦！小伙伴们，这篇关于《MyBatis商品库存管理实战教程》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！