类型转换高危在于“转得对不对”：字符串转数字需清洗再提取纯数字；数值与布尔比较应显式转换；对象互转易语义丢失；跨语言需严格遵循类型映射并管理底层细节。
类型转换看着简单，实际是程序出错的高发区。真正的问题往往不在“会不会转”，而在“转得对不对”——值变了、精度丢了、比较失效、甚至运行时崩溃，根源常常是转换前没看清数据本质。
字符串转数字：别信“看起来像数字”
用户输入、网页抓取、Excel导出的数据，表面是“123”，背后可能是“ 123\n”、“¥1,280.00”或“123abc”。直接用 int() 或 float() 会报错，更危险的是某些“看似合法”的字符串能成功转换却结果错误。
- 先用 .strip() 清除首尾空格和换行符
- 对含符号或千分位的字符串（如货币），用正则提取纯数字部分：re.sub(r"[^\d.-]", "", s)
- 避免依赖隐式转换，比如 PHP 中 "100,00" * 0.9 会丢掉小数点后内容；Python 中 "10" > "2" 是字典序比较，不是数值大小
数值与布尔的真假陷阱
很多语言把 0、空字符串、null 等当作 false，但具体规则差异很大。JavaScript 中 "0" 是 true，PHP 中 0 == "abc" 居然为 true，Python 中空列表 [] 转 bool 是 False，但跟 False 比较又等于 True。
- 条件判断中，尽量用显式转换：bool(x)、int(x)，而不是依赖隐式判断
- 涉及用户输入的逻辑（如表单校验），不要只写 if input:，要明确检查 if input.strip() != "" 或 if isinstance(input, (int, float)) and input != 0
- 在 JavaScript 中统一使用 === 替代 ==，避免松散比较带来的意外类型提升
对象与基础类型的互转：小心“假成功”
数组转字符串、日期转数字、自定义对象转 JSON……这些操作常返回“看起来正常”的结果，但语义可能已丢失。比如 [] + {} 在 JS 中是 "[object Object]"，new Date() + 1 是字符串拼接而非时间加毫秒。
- 日期运算一律用 .getTime() 或 getTimezoneOffset() 显式转时间戳再计算
- JSON 序列化前确认对象不含函数、undefined、Symbol 或循环引用
- Java 中向下转型前必须用 instanceof 检查，否则 ClassCastException 不可避免
跨语言或跨系统转换：注意底层表示差异
C 与 Python 交互时，PyLong_FromLong 和 PyLong_AsLong 必须配对使用，漏掉引用计数管理会导致内存泄漏；R 中因子（factor）保留 levels 顺序，直接转字符可能打乱分类逻辑；影刀 RPA 抓到的 Excel 数值常带隐藏格式字符，不预处理就进计算模块，结果偏差难以追溯。
- 跨语言调用务必查阅对应 API 的类型映射表，比如 C 的 char* 对应 Python 的 str，需用 PyUnicode_FromString
- R 中涉及排序或建模的分类变量，优先声明为 ordered = TRUE 的因子，并显式指定 levels
- 自动化流程中，关键转换节点添加日志：记录原始值、清洗后值、转换结果三者，便于快速定位哪一步“悄悄变了”
