nullptr 不能赋值给整数变量是因为其类型为 std::nullptr_t，仅可隐式转换为指针类型；NULL 是整型宏（如 0 或 0L），故可赋值给整数变量，但易引发类型混淆。
为什么 nullptr 不能赋值给整数变量而 NULL 可以
NULL 在多数标准库实现中是 0 或 0L 的宏定义，本质是整型常量；nullptr 是 C++11 引入的字面量，类型为 std::nullptr_t，只能隐式转换为任意指针类型，不参与整型上下文。
常见错误现象：int x = NULL; 合法但危险，int x = nullptr; 编译失败——这正是设计目的：暴露类型混淆。
- 使用场景：函数重载时，
void f(int)和void f(char*)同时存在，f(NULL)会调用f(int)（因NULL是整数），而f(nullptr)明确调用指针版本 - 参数差异：
nullptr是右值，std::nullptr_t类型不可取地址；NULL是宏，预处理阶段替换，无类型信息 - 兼容性影响：C++98/03 代码若依赖
NULL作整数用，升级到 C++11 后改用nullptr会触发编译错误，需人工审查逻辑
nullptr 在模板推导中为何更安全
模板参数类型推导对 nullptr 能准确得到 std::nullptr_t，而 NULL 会被推成 int 或 long，导致后续指针操作失效。
示例：template<typename t> void foo(T t) { static_assert(std::is_pointer_v<t>, "T must be pointer"); }</t></typename> —— foo(nullptr) 通过，foo(NULL) 编译失败（T 推导为 int）。
立即学习“C++免费学习笔记（深入）”；
- 容易踩的坑：泛型容器或智能指针构造函数中传
NULL，可能意外触发整数构造而非指针构造（如std::unique_ptr<int> p(NULL);</int>在某些旧实现中可能调用explicit unique_ptr(pointer)，但语义模糊） - 性能无差异：两者都是编译期常量，生成的机器码相同，安全性的提升不带来运行时开销
跨平台项目里 NULL 宏定义不一致带来的问题
POSIX 系统头文件常将 NULL 定义为 ((void*)0)，而 Windows SDK（尤其旧版）可能定义为 0；C++ 标准只要求 NULL 可隐式转为任意指针类型，不规定具体展开形式。
后果：在函数重载 + 模板 + 头文件包含顺序复杂的项目中，NULL 行为可能因平台或编译器不同而变化，nullptr 则完全标准化、无歧义。
- 实操建议：用
grep -r "define NULL" /usr/include（Linux）或检查windef.h（Windows）确认实际定义；但更稳妥的做法是全局搜索并替换NULL为nullptr（注意排除 C 头文件或 C 风格接口） - 混合语言项目：C++ 代码调用 C 函数时仍可传
nullptr（C++11 起保证与 C 的NULL兼容），但 C 代码不能用nullptr
什么时候还必须用 NULL？
几乎没有。唯一例外是明确需要整数零值的上下文，且不能写 0（比如历史代码风格强制所有“空值”统一用 NULL），但这属于人为约束，非技术必需。
真正需要注意的是：C 头文件（如 <stdio.h></stdio.h>）中声明的函数接受 void* 参数时，传 nullptr 完全合法；但若该函数内部做整数运算（如指针算术误用），问题不在空值表示方式，而在逻辑错误本身。
- 容易被忽略的点：
nullptr不能用于位运算（nullptr & 1报错），NULL可以（因是整数）——但这恰恰说明你在不该用空值的地方做了整数操作 - 遗留系统迁移：若代码大量使用
#ifdef __cplusplus区分 C/C++，且NULL在 C 部分被重新定义，需确保 C++ 部分不依赖其整数特性
