查单条且必须存在时用selectOne，否则优先用selectList；输入统一用nextLine()再转类型；UPDATE/DELETE必须检查WHERE条件和参数名；tinyint(1)映射Boolean需配typeHandler或用Integer判断。
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 字段会导致反序列化失败或值错乱。
立即学习“Java免费学习笔记（深入）”；
- 要么改数据库字段类型为
BIT或BOOLEAN（MySQL 实际还是TINYINT），并配typeHandler="org.apache.ibatis.type.BooleanTypeHandler" - 要么 Java 侧保持
Integer字段，用inStock != null && inStock > 0判断，更直白、无隐式转换风险 - 别信某些博客说“加
@Column就能自动转”，JDBC 驱动层不认这个注解，MyBatis 也不处理
库存管理看着简单，但 MyBatis 的参数绑定、SQL 拼接时机、JDBC 类型映射这三块，任何一个环节松一点，数据就可能静默错乱——尤其在控制台这种没有 UI 校验的场景下，错得越安静，修得越费劲。
