隐式转换在算术运算、赋值、函数传参时自动发生，不报错却可能截断或符号扩展；如unsigned char(-1)输出255、int负数赋值给unsigned转为大正数、short相加结果为int。
隐式转换什么时候发生，又为什么悄悄改了你的值
C语言在算术运算、赋值、函数传参时会自动做类型提升和转换，但这个过程不报错，只默默截断或补符号位。比如 unsigned int 和 int 混算，char 传给需要 int 的函数——编译器全给你“安排”了，你却可能完全没意识到结果已变。
常见错误现象：printf("%d", (unsigned char)-1) 输出 255；int a = -5; unsigned b = a; 后 b 变成极大正数（如 4294967291）；两个 short 相加结果却是 int 类型。
- 整型提升（integer promotion）：所有比
int小的类型（如char、short）参与运算前先转成int（或unsigned int，当int装不下原类型时） - 普通算术转换（usual arithmetic conversion）：左右操作数类型不同时，按“类型层级”向上对齐，顺序大致是
int → unsigned int → long → unsigned long → long long → unsigned long long - 赋值转换独立于上述规则：右边值直接按左边目标类型截断或重解释，不考虑上下文——这是最常踩坑的地方
(type) 强制转换不是万能胶，用错反而掩盖问题
写 (int)x 看似主动，实则只是告诉编译器“按我说的解释这块内存”，它不校验合理性，也不防止溢出或精度丢失。
使用场景有限：函数接口类型不匹配（如 qsort 的比较函数里把 void* 转回结构体指针）、需要显式丢弃高位（如取低8位：(unsigned char)x）、与无符号数交互时控制符号扩展方向。
立即学习“C语言免费学习笔记（深入）”；
- 对浮点数转整数：
(int)3.9直接截尾得3，不是四舍五入；(int)1e10在32位系统上溢出，结果未定义 - 指针强制转换要小心对齐：把
char*强转为int*后解引用，若地址未按int对齐（如奇数地址），在 ARM 或 RISC-V 上直接触发硬件异常 - 避免在表达式中间频繁强转，比如
(float)a / (float)b * (float)c—— 改用a * 1.0f / b * c更清晰且不易漏括号
有符号和无符号混用：编译器不会警告，但结果大概率不对
这是 C 隐式转换里最危险的组合。只要一边是无符号，整个表达式就按无符号规则计算，负数会变成巨大正数，然后继续参与运算。
典型错误代码：for (unsigned i = n; i >= 0; i--) —— i 永远不会小于 0，循环变成死循环；if (len - offset 中 <code>len 和 offset 是 size_t，永远进不了分支。
- 比较操作符（
、<code>==等）也触发普通算术转换：int x = -1; unsigned y = 1; x 实际比较的是 <code>4294967295U ，结果为假 - 函数参数传递不触发隐式转换来“修正”符号性，只按声明类型接收：如果函数形参是
unsigned，传入负的int就直接重解释，调用者必须自己确保逻辑合理 - 用
-Wsign-compare编译选项能捕获大部分混用比较，但无法覆盖赋值或算术表达式中的隐式转换
怎么写才不容易翻车：几个具体可执行的习惯
没有银弹，但有几条硬约束能大幅降低出错概率。
- 变量声明时就定好符号性：长度、索引、计数器优先用
size_t；明确要存负值的用int；别用unsigned单纯为了“表示更大范围” - 跨类型运算前手动统一：比如
ssize_t offset = ...; size_t len = ...;，比较前写成offset >= 0 && (size_t)offset - 对关键转换加注释并验证边界：例如
uint8_t x = (uint8_t)(val & 0xFF); // 截低8位，忽略高位溢出 - 调试时多看汇编输出（
gcc -S）或用sizeof、printf("%#x")打印中间值——隐式转换看不见，但结果骗不了人
类型转换真正难的不是语法，而是每次运算背后那套隐含的整型提升路径和符号传播逻辑。你得习惯在心里默读一遍“这俩现在各自是什么类型？提升后呢？运算完再赋给谁？中间有没有截断或重解释？”——少一次默读，就多一个深夜调试的 bug。
