推荐使用 while(true)，因其语义明确、类型安全且为C++11起标准写法；for(;;)虽兼容旧标准但易出错。死循环必须含显式退出机制（如break/return），并避免资源泄漏、CPU满载及阻塞导致的假死现象。
死循环写法：while(true) 和 for(;;) 本质一样
两者在编译器眼里几乎等价，生成的汇编指令通常完全一致。选哪个纯看团队习惯或代码上下文风格——while(true) 更直白，for(;;) 更紧凑。
常见错误是误写成 while(1) 或 while(!0)：虽然合法，但可读性差，且某些静态分析工具会警告非布尔字面量作条件（比如 Clang 的 -Wbool-conversions）。
-
while(true)是 C++11 起推荐写法，语义明确，类型安全（true是bool） -
for(;;)兼容更老标准（C++98 也支持），但三个分号空着，新手容易漏掉某个分号写成for(; ;)（虽合法）或误加内容 - 别用
while(1 == 1)这类冗余表达式，编译器可能优化掉，但代码意图模糊
必须配 break 或 return，否则真就“死”了
死循环不是目的，而是为等待某个外部条件（比如用户输入、网络响应、信号）而存在的容器。没退出机制的死循环在单线程程序里等于卡死。
典型场景：嵌入式主循环、服务器 accept 循环、游戏帧循环。
立即学习“C++免费学习笔记（深入）”；
- 退出逻辑必须放在循环体内，不能依赖外部变量“突然变假”——除非配合
volatile或原子操作（如std::atomic<bool></bool>） - 避免在循环中频繁调用阻塞函数（如无超时的
std::cin.get()），否则无法响应中断或退出信号 - 如果循环体里有
continue，注意别跳过退出判断逻辑，导致漏检终止条件
示例：
while (true) {
auto msg = receive_message(); // 可能返回空
if (!msg.has_value()) break; // 显式退出点
process(msg.value());
}
调试时卡住？先确认是不是真死循环，还是被阻塞了
现象是程序“不动了”，但未必是逻辑错误导致的无限循环——更常见的是 I/O 阻塞、锁竞争、信号未处理。
用 gdb attach 进程后执行 bt，看栈顶是不是停在 read、pthread_cond_wait 或 std::mutex::lock 上。
- Linux 下可用
strace -p <pid>查看系统调用是否卡在recvfrom或epoll_wait - 若用了
std::this_thread::sleep_for，检查时间单位是否写错（比如把ms写成s，实际睡一小时） - 多线程下，一个线程死循环可能饿死其他线程——尤其在单核或
std::this_thread::yield()缺失时
性能与可维护性：别让死循环变成“黑洞”
死循环本身开销极小，但里面的内容决定一切。最常被忽略的是资源泄漏和状态漂移。
- 每次循环迭代都 new 但不 delete → 内存泄漏（用 RAII 或智能指针）
- 循环内打开文件但不 close → 文件描述符耗尽（
EMFILE错误） - 没做节流（如无休止轮询
is_data_ready()）→ CPU 占用 100% - 日志打太密（比如每毫秒一条）→ 磁盘 IO 拖垮整个服务
复杂点在于：退出条件往往来自异步事件（信号、回调、共享内存更新），而这些机制本身就有竞态和延迟。别假设“只要变量变了，下一轮循环就立刻看到”。
