暴力匹配易因越界读、内存区域过滤不当或位数混用导致漏匹配；KMP需适配字节流特性，避免字符串假设，通配符场景须降级为暴力+位掩码。
暴力匹配在小数据量下够用，但扫描整个进程内存时容易卡死或漏匹配；KMP 能避免回退，但必须正确处理字节序列的边界与不完整模式。
暴力匹配：为什么 memcmp 容易漏掉跨页/跨段的匹配
直接对每字节起始位置调用 memcmp 看似简单，但实际中常因以下原因失败：
- 目标模式长度为 8 字节，而扫描到内存末尾只剩 3 字节时，
memcmp会越界读 —— 触发访问违规或静默返回假阴性 - Windows 下用
VirtualQueryEx获取内存区域后，若未跳过MEM_FREE或MEM_RESERVE区域，ReadProcessMemory会失败，但循环仍继续，导致大量无效重试 - 未考虑目标进程是 32 位而当前工具是 64 位（或反之），
SIZE_T与DWORD混用造成地址截断
实操建议：先用 VirtualQueryEx 过滤出 MEM_COMMIT | PAGE_READABLE 的块，再对每块做「剩余长度 ≥ 模式长度」的预判，最后用 ReadProcessMemory 一次性读入缓冲区，本地 memcmp。
KMP 预处理：字节数组不能直接套用字符串 KMP
标准 KMP 的 next 数组依赖字符可比较且有明确「相等」语义，而内存搜索中：
立即学习“C++免费学习笔记（深入）”；
- 字节是
uint8_t，无大小写、无编码层，但存在全零、重复高字节等特殊 pattern，需用std::vector<uint8_t></uint8_t>存储而非std::string（后者可能误截断\0） -
next[0] = -1是常见写法，但用于字节流时，索引偏移易错 —— 建议统一用int下标，且构建时用pattern[i] == pattern[len]判断，不依赖任何 string 成员函数 - 若模式含通配符（如
??表示任意字节），KMP 不适用，必须降级为暴力 + 位掩码匹配
简短示例（KMP 构建）：
std::vector<int> build_next(const std::vector<uint8_t>& pattern) {
int len = 0;
std::vector<int> next(pattern.size(), 0);
for (int i = 1; i < pattern.size(); ) {
if (pattern[i] == pattern[len]) {
len++;
next[i++] = len;
} else if (len != 0) {
len = next[len-1];
} else {
next[i++] = 0;
}
}
return next;
}跨平台读取：Linux 的 /proc/pid/mem 与 Windows 的 ReadProcessMemory 关键差异
两者权限模型和错误反馈完全不同，不能共用一套异常逻辑：
- Linux 下打开
/proc/pid/mem需ptrace(PTRACE_ATTACH)权限，否则open()直接失败；而 Windows 中OpenProcess(PROCESS_VM_READ)失败后，还需检查是否缺少SeDebugPrivilege - Linux 读取时若遇不可读页，
read()返回 -1 并设errno = EIO；Windows 中ReadProcessMemory返回FALSE，必须调GetLastError()判定是ERROR_PARTIAL_COPY还是ERROR_ACCESS_DENIED - Linux 下需按
getpagesize()对齐读取起点，否则部分页可能被跳过；Windows 中地址无需对齐，但跨页读取仍要分两次ReadProcessMemory调用（系统不保证单次调用跨越保护边界）
实操建议：封装统一接口 bool read_memory(HANDLE hProc, uintptr_t addr, void* buf, size_t len)，内部按平台分支处理错误与重试逻辑，上层只管调用。
真实场景下的性能陷阱：为什么多线程扫内存反而更慢
看似把内存分块丢给多个线程能加速，但实践中往往适得其反：
- 频繁调用
ReadProcessMemory或read()是系统调用，上下文切换开销远高于 CPU 匹配 —— 单线程批读 + 内存内 KMP 反而更快 - 若用
std::async启动数十个线程扫不同区域，Windows 下ReadProcessMemory会争抢同一个内核对象锁，出现明显排队等待 - 没有预分配读缓冲区，每个线程临时
new几 MB 内存，触发频繁堆分配与 TLB miss
真正有效的优化是：单线程顺序读取大块（如 1MB），用 mmap（Linux）或 CreateFileMapping（Windows）做零拷贝映射，再对映射区跑 KMP；匹配到后记录虚拟地址，不立即读后续内容。
最易被忽略的一点：内存搜索结果里的地址是目标进程的 VA，不是你进程的；直接解引用会崩。所有匹配到的地址，必须再走一遍 ReadProcessMemory（或 read）才能拿到真实值 —— 这步不能省，也不能靠“大概率可读”跳过校验。
