应优先在数据入口做前置校验与清洗：用strip()清理空白，对可能含小数点的字符串先float再int，明确进制时传base参数，避免依赖isdigit()等易误判方法，关键处使用带default的safe_int()函数并分层校验语法与语义。
字符串转数字时遇到ValueError: invalid literal for int()怎么办
直接抛异常不是错，但生产环境里让程序崩在int("abc")这种地方，说明校验没做在数据入口。关键不是“怎么捕获异常”，而是“在哪、用什么策略提前拦住非法输入”。
常见错误现象：int("12.3")、int(" 123 ")（看似可转但带空格有时会意外失败）、int("0x1F")（十六进制不加base参数直接报错）、float("inf")转int也挂。
- 先用
str.strip()清理首尾空白，避免" 42 "这类干扰 - 对可能含小数点的字符串，优先用
float()尝试，再判断是否为整数（is_integer()），而不是硬上int() - 明确预期进制时，必须传
base参数，比如int("1010", base=2)，否则默认按十进制解析 - 别依赖
type(x) is int来判断——字符串转完才是int，校验阶段只看原始str
用str.isdigit()和str.isdecimal()能替代try/except吗
不能，而且容易误判。这两个方法只对纯阿拉伯数字字符返回True，连负号"-123"、小数点"12.3"、全角数字"１２３"都会返回False，但它们其实都能被float()或int()合法转换。
使用场景很窄：仅当你**严格限定输入只能是无符号十进制整数字符串**，且确认不含任何 Unicode 变体时，才考虑用.isdecimal()（比.isdigit()更严格，排除上标/下标数字）。
立即学习“Python免费学习笔记（深入）”；
-
"123".isdecimal()→True；"-123".isdecimal()→False（但int("-123")完全合法） -
"½".isdigit()→True（Unicode 分数），但int("½")报错 - 真正安全的前置校验，还是得靠
try/except包裹转换逻辑，而非字符串方法
写一个复用的safe_int()函数要注意哪些边界
核心原则：不隐藏问题，不擅自默认值。返回None可以，返回0要谨慎——因为0本身是有效数字，一旦下游用if safe_int(s) == 0判断，就和“转换失败”语义混淆了。
性能影响很小，但调用频次高时，避免重复.strip()或正则预检——不如直接try，Python 的异常开销在现代解释器里已优化很多。
- 支持可选
default参数，但显式传default=None比留空更清晰 - 不自动处理
float字符串如"12.0"，除非加allow_float=True开关并内部做int(float(x)) - 对
None输入应单独判断，避免None.strip()报AttributeError - 示例：
def safe_int(s, default=None): if s is None: return default try: return int(str(s).strip()) except (ValueError, TypeError): return default
JSON 或 CSV 里读出的数字字段为什么总报ValueError
因为 JSON 标准里null对应 Python 的None，但 CSV 解析器（如csv.DictReader）常把空单元格读成空字符串""，而int("")必然炸。更隐蔽的是 Excel 导出的 CSV 可能含不可见字符（如\ufeff BOM、零宽空格），strip()也清不掉。
兼容性影响大：不同来源的数据格式约定不一，硬编码int(row["age"] or "0")会把空字符串变0，掩盖真实缺失。
- 从文件读取后，立即对关键数字字段批量清洗，例如用
map(lambda x: x.strip().replace("\ufeff", ""), row.values()) - 用
csv.Sniffer检测分隔符和引号规则，避免字段分割错位导致数字串被截断 - 调试时打印
repr(s)而不是print(s)，才能看到隐藏字符 - 如果上游可控，要求 JSON 用
0或null表示缺失，避免用空字符串
int("999999999999999999999")不会报ValueError，但它可能远超数据库字段长度或业务阈值。校验永远要分两层：语法合法（parseable），语义合理（in range / not negative / within business rules）。 
