Java数据库实战：结合MyBatis与控制台实现商品库存管理

查单条且必须存在时用selectone，否则优先用selectlist；输入统一用nextline()再转类型；update/delete必须检查where条件和参数名；tinyint(1)映射boolean需配typehandler或用integer判断。

java数据库实战：结合mybatis与控制台实现商品库存管理_持久层入门

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 = ?——整张表库存全变。

js2java

JavaScript 到 Java 全栈翻译助手，专为前端开发者学习 Java 或快速实现后端业务逻辑而设计。当用户提到以下场景时必须使用此技能： - "帮我把这段 JS 代码转成 Java" - "用 Java 怎么写这个逻辑" - "我习惯用 JS 写，想翻译成 Java" - "教我 Java，我要写后端接...

下载

所有 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 校验的场景下，错得越安静，修得越费劲。