手写字符串转数字需谨慎处理符号位、溢出及非法字符：先跳过前导空格，识别正负号，再逐位用Character.isDigit()校验并累加；溢出判断须提前进行，避免乘法后溢出。
手写循环解析字符串转数字的边界处理
手动遍历字符做数值转换时，最容易出错的是符号位、溢出判断和非法字符跳过逻辑。比如 "-123" 要先识别负号，再逐位累加；而 " -456abc" 这类带前导空格和尾部乱码的输入，标准库会截断或抛异常，但手写必须自己决定是否容忍。
- 用
charAt(i)遍历时，务必先用Character.isDigit()判断，别直接减'0'，否则遇到'-'或空格会得到负值 - 溢出检测不能等乘完再比：要提前判断
result > (Integer.MAX_VALUE - digit) / 10，否则result * 10 + digit已经溢出，结果不可靠 - 前导空格用
while (i 跳过，但注意别越界；符号位只允许出现在开头（且仅一个），后续再出现就该报错
Java自动类型转换（Integer.parseInt()）的隐式行为
Integer.parseInt() 看似简单，但它内部做了不少隐性决策：比如严格要求整个字符串必须是有效整数格式，"123abc" 直接抛 NumberFormatException，不会像 C 的 strtol 那样返回已解析部分；而且它不接受前导加号（"+123" 是合法的，但很多老版本 JDK 或特定 locale 下可能不一致）。
- 默认按十进制解析，想支持十六进制得显式传参：
Integer.parseInt("FF", 16) - 空字符串、纯空格、null 都会触发
NumberFormatException，不是返回 0 或默认值 - 如果字符串长度超过 10 位（int 范围上限是 10 位数），即使内容合法，也可能在解析中途因溢出提前失败
手写 vs 自动转换：性能与可控性的取舍
纯数字字符串下，Integer.parseInt() 比手写循环快——JVM 对其做了内联和底层优化；但一旦需要定制行为（比如忽略所有非数字字符、支持逗号分隔符、容错跳过单位字母 "12.5MB"），手写反而更轻量、更明确。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 手写可控制精度：比如只取前 8 位数字，或遇到小数点就截断，而
parseInt()遇到小数点直接报错 - 自动转换依赖
Locale设置（极少见），某些区域设置下会把逗号当小数点，导致意外解析失败 - 手写循环中用
long result中间存储能延缓溢出，再转int前统一校验，比反复拆解parseInt的 try-catch 更高效
容易被忽略的 Unicode 和编码陷阱
Java 字符串是 UTF-16，但数字字符不只有 ASCII 的 '0'–'9'。比如全角数字 '０'（U+FF10）或阿拉伯文数字 '٠'（U+0660），Character.isDigit() 会返回 true，但减 '0' 会得到错误值。手写解析若没考虑这点，就会把 "１２３" 解成完全错误的数字。
立即学习“Java免费学习笔记（深入）”；
- 若需兼容全角数字，应改用
Character.digit(ch, 10)，它能正确映射各种 Unicode 数字字符 -
parseInt()只认 ASCII 数字，遇到全角字符直接抛异常，反而是种“安全失败” - 从外部读入字符串时（如 HTTP 参数、文件），务必确认编码，否则
new String(bytes, "ISO-8859-1")错用编码可能导致数字字符变成乱码，解析必然失败
