long 转 int 会溢出吗
会，而且不报错、不抛异常，直接截断——这是 C++ 内置类型转换的默认行为。只要 long 值超出了 int 的取值范围（通常是 −2,147,483,648 到 2,147,483,647），结果就是未定义行为（UB）或实现定义行为（取决于符号和平台），常见表现是高位丢弃、数值“绕回”。
比如在 64 位 Linux 上，long 是 64 位，int 是 32 位，static_cast<int>(3000000000L)</int> 得到的是负数（因为高位被砍掉，符号位变了）。
- 溢出不是编译错误，连警告都未必有（除非开
-Wconversion且编译器支持） - 32 位系统上
long和int可能都是 32 位，此时转换安全——但不能依赖，可移植代码必须假设它们不同 -
static_cast、C 风格强制转换、函数参数隐式转换，都会触发这种静默截断
如何安全地把 long 转成 int
核心思路：先检查范围，再转换。别信“我这数据肯定不越界”，运行时输入、外部接口、计算中间值都可能打破假设。
推荐用 std::numeric_limits 做边界判断：
立即学习“C++免费学习笔记（深入）”；
if (val >= std::numeric_limits<int>::min() &&
val <= std::numeric_limits<int>::max()) {
int i = static_cast<int>(val);
} else {
// 处理溢出：抛异常、返回错误码、截断并记录日志等
}
- 别用
INT_MIN/INT_MAX（来自<climits></climits>），它们是宏，不保证与目标int类型完全一致（尤其模板场景） - 如果项目用 C++20，可考虑
std::cmp_less_equal(val, std::numeric_limits<int>::max())</int>避免有无符号比较警告 - 避免手写常量如
-2147483648，易错且不可读
为什么不能用 reinterpret_cast 或 memcpy
有人想绕过类型检查，用 reinterpret_cast<int>(val)</int> 或 memcpy(&i, &val, sizeof(int)) —— 这更危险。
-
reinterpret_cast对非 trivially copyable 类型无效，对整型虽不报错，但语义上是“按位重解释”，在大小不同时读取未初始化内存（long比int宽时）是未定义行为 -
memcpy看似“只是搬字节”，但若sizeof(long) > sizeof(int)，你只复制了低字节，高位丢失且无提示；若sizeof(long) （少见但合法），则目标内存未完全覆盖，残留垃圾值 - 两者都绕过了范围检查，等于主动放弃安全性
long 到 int 转换在跨平台代码里特别容易翻车
Windows 上 long 是 32 位，Linux/macOS 上通常是 64 位——同一段代码，在 VS 编译时看似正常，GCC/Clang 下一跑就出错。
- 不要写
long x = ...; int y = x;这类裸转换，尤其在函数返回值、结构体成员赋值、容器初始化中 - 如果必须存为
int，优先考虑是否真需要窄类型：用long或int64_t/int32_t显式替代，比反复转换更可靠 - CI 流水线里至少跑两个平台（x86_64 Linux + Windows MSVC），开启
-Wconversion -Wsign-conversion才能提前暴露问题
最麻烦的不是转换本身，而是溢出后程序继续跑、结果错得不明显——比如坐标偏移、计时器跳变、数组索引越界却没 crash，查起来要花几小时。
