使用 std::search 查找二进制序列时，必须统一用 uint8_t 避免符号扩展问题；替换需分配新缓冲区或确保新序列不长于原序列，并跳过已处理区域防止重复匹配；跨平台应显式使用十六进制后缀U，大文件推荐 mmap + 分块重叠读取提升性能。
用 std::search 找二进制序列，但要注意迭代器类型
直接用 std::search 在 std::vector<uint8_t></uint8_t> 或裸指针内存块里找字节序列是可行的，但必须确保搜索范围和模式都用相同底层类型——不能混用 char 和 uint8_t，尤其在 Windows 上 char 是有符号的，遇到 0xFF 会变成 -1，导致匹配失败。
常见错误现象：std::search 返回 end()，哪怕目标序列明明存在；调试发现模式中某个字节被解释成负数，operator== 比较失败。
- 统一用
uint8_t定义数据容器和模式，避免符号扩展干扰 - 若只能用
char*（如从fread读出），搜索前把模式字节显式转为unsigned char再构造成std::vector - 别用
std::string存二进制数据——它可能在\0处截断，且.data()不保证空终止
替换时必须处理内存重叠与容量变化
二进制流替换不是字符串替换：原序列和新序列长度大概率不等，直接 memcpy 覆盖会越界或遗漏；若原地替换且新序列更长，后面数据会被覆盖；若更短，会留下“空洞”。
使用场景：patch 固件、修改 PE 文件头、篡改加密载荷——这些都不允许破坏后续结构对齐。
立即学习“C++免费学习笔记（深入）”；
- 安全做法是分配新缓冲区，用
std::vector<uint8_t></uint8_t>累加：匹配前内容 + 新序列 + 匹配后剩余内容 - 若必须原地操作（如 mmap 映射的大文件），先确认新序列 ≤ 原序列长度，再用
memmove向后挪动后续数据（注意memmove支持重叠，memcpy不保证） - 替换多次时，每次搜索起点要跳过已处理区域，否则可能反复匹配同一位置（比如模式
{0x00, 0x01}替换为{0x01}，不跳过会导致无限循环）
跨平台十六进制字面量写法要显式加 0x 和类型后缀
C++23 之前没有原生二进制字面量支持十六进制序列，手写 0xFF 看似简单，但容易因类型推导出错：比如 {0xFF, 0x00} 初始化 std::vector<char></char>，在 clang 上可能推导为 int 列表，触发隐式转换警告甚至截断。
参数差异：0xFF 是 int 字面量，赋值给 uint8_t 会窄化；而 static_cast<uint8_t>(0xFF)</uint8_t> 明确无歧义。
- 定义模式时统一用
std::vector<uint8_t>{0xFFU, 0xAAU, 0x55U}</uint8_t>，U后缀防止被当有符号整数 - 读取文件到内存时，用
fread+uint8_t*缓冲区，别用fscanf("%hhx", ...)——它依赖 locale 且极慢 - 调试打印字节时，用
printf("%02x", (unsigned int)b)，强制升为unsigned int避免char符号扩展影响输出
大文件搜索性能瓶颈不在算法，而在 I/O 和缓存局部性
用 std::search 扫一遍几百 MB 的二进制文件，耗时主要卡在磁盘读取和缺页中断，不是 CPU 比较慢。朴素实现每读 4KB 就搜索一次，会产生大量小 I/O 和 cache miss。
性能影响：未预读、未对齐的访问会让 SSD 实际吞吐跌到 1/5；用 mmap 可缓解，但 32 位程序 mmap 超大文件会失败。
- 分块读取时，块大小设为 64KB～1MB，让 OS 预读生效；每块末尾保留至少
pattern.size()-1字节与下一块重叠，防止跨块边界漏匹配 - Linux 下优先用
mmap+madvice(POSIX_MADV_WILLNEED)，Windows 用CreateFileMapping；避免std::ifstream::seekg频繁跳转 - 如果只是查找不替换，可考虑
Boyer-Moore-Horspool实现（如 Boost.Algorithm 的boyer_moore_search），对长模式加速明显，但短模式（≤8 字节）反而更慢
最易被忽略的是：二进制搜索不保证“唯一上下文”。同一个字节序列可能在代码段、数据段、资源节里重复出现，盲目全局替换会直接搞崩可执行文件——动手前务必用 objdump 或 readelf 确认目标位置的语义。
