raii封装文件句柄需构造时open()失败抛异常、析构时无条件close()、禁拷贝、移动后置源fd为-1、提供get()但禁隐式转换；网络socket应分离句柄与连接状态，构造仅socket()，connect()作为独立方法；std::fstream不适用底层系统调用场景，避免混用fd导致双重关闭。
RAII封装文件句柄：别直接用int fd裸奔
裸open()返回的int不是资源，是泄漏隐患。RAII要求构造即获取、析构即释放，且必须保证异常安全。
常见错误是写个简单包装类但忘了close()可能失败，或在移动语义里没置空源对象的fd——导致两次close()或悬空句柄。
- 构造函数调用
open()，失败时抛异常（不设默认值） - 析构函数无条件调用
close()，忽略返回值（POSIX规定close()失败不影响资源释放） - 显式删除拷贝构造/赋值；移动构造后把原
fd设为-1 - 提供
get()返回int，但不提供隐式转换——避免意外传给C函数后被误关
class FileDescriptor {
int fd_ = -1;
public:
explicit FileDescriptor(const char* path) : fd_(open(path, O_RDONLY)) {
if (fd_ == -1) throw std::system_error(errno, std::generic_category());
}
~FileDescriptor() { if (fd_ != -1) close(fd_); }
FileDescriptor(FileDescriptor&& rhs) noexcept : fd_(rhs.fd_) { rhs.fd_ = -1; }
FileDescriptor& operator=(FileDescriptor&& rhs) noexcept {
if (this != &rhs) { if (fd_ != -1) close(fd_); fd_ = rhs.fd_; rhs.fd_ = -1; }
return *this;
}
int get() const noexcept { return fd_; }
};网络连接的RAII：TCP socket不能只管connect()
socket句柄本身可RAII，但“已连接”状态不是构造函数能保证的。很多封装一上来就connect()，结果阻塞或超时，又没法在构造里合理处理。
更现实的做法是分离“句柄生命周期”和“连接状态”。句柄由RAII管理，连接逻辑交给独立方法，失败时抛异常，用户自行决定重试或放弃。
立即学习“C++免费学习笔记（深入）”；
中国最实用的办公自动化系统，全面提升单位的工作效率和质量，整合企业资源，规范办公流程，加快信息流通，提高办公效率，降低办公成本，通过提高执行力来完善管理，从而提升企业竞争力 含公告通知、文件传送、电子通讯薄、日程安排、工作日记、工作计划、个人（公共）文件柜、网上申请和审批、电子邮件、手机短信、个人考勤、知识管理、人事管理、车辆管理、会议管理、印信管理、网上填报、规章制度、论坛、网络会议、语音聊天、
- 构造只调用
socket()，不碰connect()或bind() - 提供
connect(const sockaddr*, socklen_t)成员函数，失败抛std::system_error - 析构前若
fd_ != -1，调用shutdown(SHUT_RDWR)再close()——避免TIME_WAIT残留或对端收不到FIN - 注意
AF_INET6下IN6ADDR_ANY_INIT初始化地址结构体，别漏memset()
RAII与C++标准库的冲突点：std::fstream不等于RAII文件管理
std::fstream确实自动关闭，但它封装的是C标准I/O（FILE*），不是POSIX文件描述符。这意味着你无法把它传给epoll_ctl()、sendfile()或splice()这类系统调用。
如果项目混合使用C++流和底层IO，容易出现双重关闭：比如用std::ofstream打开文件，又用fileno()取FILE*的fd去注册到epoll——析构时ofstream关一次，epoll事件触发后你再close()一次，EBADF就来了。
- 明确区分用途：
std::fstream用于格式化读写；自定义RAII类用于需要fd的场景 - 不要从
std::fstream里提取fd（fileno()返回的fd不可靠，C++标准未规定其行为） - 若必须桥接，用
dup()复制fd，并确保原始fstream不再参与IO
析构函数里调close()或shutdown()真安全吗？
安全，但有前提：不能在析构里做可能抛异常的操作，也不能依赖其他可能已销毁的对象。比如在析构里调用std::cout ，而此时<code>std::cout可能已被销毁，程序直接abort。
另一个坑是信号上下文：某些异步信号（如SIGPIPE）可能中断write()，触发析构，而析构里再调close()属于异步信号不安全函数——但这通常发生在多线程+信号混用的边缘场景，单线程服务中影响小。
- 析构函数必须是
noexcept（C++11起默认满足） - 避免在析构里调用任何可能分配内存、锁互斥量、或输出日志的函数
- 系统调用如
close()、shutdown()、munmap()是安全的，但要检查返回值仅用于诊断，不据此改变流程 - 真正危险的是：把RAII对象放在全局/静态区，其析构顺序不可控，可能依赖已被销毁的logger或config单例
最常被忽略的一点：RAII解决的是“谁来释放”，不是“何时释放”。对象生命周期仍由作用域或智能指针决定，别指望它自动适配异步回调或跨线程传递的场景。
