C++

GPGGA解析需手动按逗号切分并保留空字段，避免std::stringstream跳过空值导致字段错位。经纬度采用度分格式，需转换为十进制度数并处理方向。校验和应对$后至*前字符异或，结果转大写比对。UTC时间转换需使用timegm或_mkgmtime避免时区干扰，且日期需从其他帧获取。

C++内存池需处理对齐、构造、析构与空闲链表管理。直接newchar[N]无法保证对齐和生命周期，导致对象读取崩溃或析构跳过清理。需用std::aligned_storage按alignof(T)对齐，显式调用构造析构，freelist指针存放在块头部，并确保对象大小不小于指针宽度。placement-new失败常因复制构造函数删除、异常规范冲突或全局状态干

二进制协议解析需避免直接使用struct与memcpy，因填充、对齐和字节序可能导致数据错乱。手动序列化每个字段更可靠，使用#pragmapack或手动解析，网络字节序用ntohs/ntohl转换。若协议指定小端需手动反转。解析函数应返回错误码，进行边界检查与校验和验证。

weak_ptr不持有引用计数，不能直接解引用，必须通过lock()获取shared_ptr以安全访问对象。在观察者模式中，用weak_ptr存储Subject引用可避免循环引用，Subject销毁后lock()返回空。lock()与expired()各有用途，且需注意线程安全与裸指针陷阱。

基于单消费者模型，通过无锁队列实现业务线程与I/O线程解耦，避免fwrite阻塞。落盘线程采用批量定时刷盘策略，累积1024条或间隔100ms调用flush，关键节点才调fsync。日志滚动利用原子替换文件句柄实现平滑过渡，避免丢消息。

集合交集算法要求输入区间有序，本质是双指针归并，线性扫描比对。输出迭代器需足够空间，推荐后插入迭代器以保证输出正确。重复元素按最小频次保留。该算法时间复杂度为线性，常数小且缓存友好，效率非常高。

在Windows平台，使用`MultiByteToWideChar`与`WideCharToMultiByte`组合实现UTF-8与GBK互转，需经UTF-16中转并指定代码页936。务必先调用一次获取所需缓冲区大小，再分配内存；检查返回错误码（如`ERROR_INSUFFICIENT_BUFFER`）；避免使用已弃用的`std::codecvt_utf8`

C++中std::mem_fn绑定成员函数易出现编译失败和生命周期问题，推荐使用lambda替代。lambda可通过捕获this（需保证对象存活）、共享指针（推荐异步场景）或值拷贝（小对象）实现安全回调。对象生命周期管理是可靠性的关键。

std::align用于在已有内存块中查找满足对齐要求的子区域起始地址，并更新指针与剩余空间，不分配或释放内存。失败返回nullptr。需配合placementnew手动管理生命周期。对齐值必须为2的整数幂，且输入空间足够。

MODBUS协议的CRC16与标准CRC-16-IBM存在四个关键差异：初始值需为0xFFFF、输入输出均不取反、多项式固定0x8005。手写查表法实现时，生成表初始余数为0x0000，实际计算初始余数设为0xFFFF，逐字节查表后右移8位异或，最终结果无需后处理。发送时低位字节在前，推荐用std::span封装输入以避免裸指针风险。

Windows剪贴板操作注意事项：打开剪贴板失败常因线程无消息队列，需先调用窥探消息函数以创建消息队列；读取文本应优先使用宽字符文本格式以避免乱码；延迟渲染机制会导致读取后内容被清空，需读取后立即重新调用设置剪贴板数据函数以保留数据。

C++手写vector扩容需分配新内存并逐个移动/拷贝构造，不能使用memcpy处理非平凡类型（如std::string），否则引发悬垂指针或双释放。扩容策略采用乘性增长（如×2）实现摊还O(1)复杂度。对move-only类型需用trait判断优先移动。必须保证异常安全：构造失败时析构已构造元素并释放新内存。

操作BMP位图文件头时需注意内存对齐，用#pragmapack(2)确保结构体字段正确；bfOffBits是像素数据起始偏移，需考虑调色板及压缩类型；修改宽高后必须重算bfSize和每行对齐padding；像素数据按biBitCount逐字节访问，注意bottom-up存储顺序与反转。

std::distance对随机访问迭代器高效（O(1)），对list等前向迭代器退化为O(n)遍历。常见误用包括迭代器顺序颠倒和跨容器操作，均属未定义行为。随机访问容器推荐直接减法，list需频繁求距时应考虑设计调整。

std::ifstream 不支持多线程并发读取同一实例，必须采用文件分片+独立流实例+seekg()定位；更优方案是pread()或mmap()。 大文件读取卡在 std::ifstream 单线程吞吐上？别硬扛 先抛个结论：C++ 标准库里的 std::ifstream，天生就不支持多线程并发读

std::apply将tuple元素展开为函数参数，类型严格匹配，不支持隐式转换。成员函数需通过lambda或bind_front绑定对象。注意完美转发以及元组内不可复制类型的移动语义，适用于泛型编程。

C++17可用std::filesystem递归遍历目录并累加file_size()，需捕获异常跳过不可读文件。Windows下使用FindFirstFileExW手动递归，注意路径长度与宽字符。Linux/macOS结合opendir与lstat()，避免符号链接和硬链接重复统计。核心是区分逻辑字节数与物理磁盘占用，前者直接累加即可。

先说结论：在C++里实现LRU缓存，最靠谱的方案，还是手写一个双向链表，搭配一个存着节点裸指针的哈希表。直接用std::list替代，看着很美，但实操起来，坑比想象中多。 为什么 std::list 不能直接替代自定义双向链表 理论上，std::list::erase(iterator) 确实是 O

用 C++ 生成 HTML 报表，说起来不算什么高难度动作，但实际操作中翻车的点往往不在算法逻辑，而是一些看似不起眼的细节——乱码、路径转义失败、表格结构错乱，尤其是 Windows 环境下中文文件名和特殊字符（比如 &、"; break; case '"': out += """; break;

先说说核心原则：增量读取，很多新手都会栽在“我以为我读到了”这个坑里。它不是一个简单的fseek定位问题，而是一个状态机，必须保证每次读到的数据边界和记录的偏移量完全对齐。否则，要么漏读，要么重复读，日志文件一大，问题就出来了。 LastReadOffset 的真面目：不是你想设，想设就能设 简单来

Windows 下最直接的办法：GetFileTime 在Windows上，GetFileTime 是获取文件创建、最后访问和最后修改时间的老牌API。它返回一个 FILETIME 结构，这个结构是一个64位的数值，单位是100纳秒，从1601年1月1日UTC开始算起，所以你得把它转成本地时间才能看

std::bind因内部动态分配和类型擦除，比等价lambda慢10%-30%。lambda是零成本抽象，可被编译器内联优化。现代C++应禁用std::bind，改用lambda，并注意捕获方式以避免性能与生命周期问题。

C++17的std::visit本质是单重派发，处理多个variant需嵌套调用，但易引发类型推导错误与编译问题。通过overloaded辅助类合并lambda实现多参数重载分发，可解决嵌套冗长与类型冲突，但需注意分支覆盖与返回类型一致，避免组合爆炸导致维护成本上升。