“平铺”非标准术语，实指三类展平操作：多行去格式、结构化文本提取合并、分块无边界拼接；其拖慢长文本搜索主因是信息密度下降、内存膨胀、索引失效及重复计算；推荐流式处理、结构锚点定位、边界感知分块与预编译索引替代。
“平铺”（Flattening）在字符串处理语境中并不是一个标准术语，它**不指代某种通用的字符串算法或语言特性**，而是某些特定场景下对“将嵌套/分段/结构化文本展开为单一连续字节序列”这一操作的非正式描述。理解它对长文本搜索性能的影响，关键在于厘清它实际对应的技术动作及其副作用。
所谓“平铺”，通常指这三类操作
1. 多行字符串或模板字面量拼接后去换行、去缩进
例如 Python 的 textwrap.dedent() 或手动 .replace("\n", " ").replace(" ", " ")，把格式化的代码块或文档变成一行纯文本。这会丢失原始结构信息，但让正则或关键词搜索更“宽松”。
2. JSON/XML/HTML 内容提取后的纯文本展平
比如用 BeautifulSoup.get_text() 或 jsonpath 提取所有叶子节点文本，再用空格连接。结果是“标题正文段落列表项”这样的无结构串，长度可能激增数倍，且引入大量无关空白和分隔符。
3. 分块读取后未做边界处理的简单合并
为处理大文件而分片读取（如每次读 64KB），若直接 buffer += chunk 而不检查跨块的模式边界（如搜索词 "ing" 恰好被切在 "runn" 和 "ing" 之间），就属于一种危险的“平铺”——表面连续，实则破坏匹配完整性。
它为什么拖慢长文本搜索
• 有效信息密度下降：加入大量空格、换行符、HTML标签残留后，目标模式在文本中占比变小，暴力或 KMP 等算法需扫描更多无意义字符。
• 内存占用翻倍：原始 10MB 的 HTML 文件经 get_text() 展平后可能膨胀为 15–20MB 纯文本，超出 L1/L2 缓存容量，触发频繁内存带宽争用。
• 破坏索引友好性：Trie 或倒排索引依赖原始 token 边界；平铺后词边界模糊（如 “user login” 变成 “userlogin”），导致预建索引失效，被迫退回到逐字符扫描。
• 引发重复计算：若在循环中对同一文档反复“平铺+搜索”，等于每次重建输入，而本可复用一次展平结果或直接流式匹配。
更优的替代思路
• 流式处理代替全量平铺：用支持增量解析的库（如 Go 的 bufio.Scanner 配合状态机，或 Python 的 sax 解析器），边解析边匹配，不落地完整文本。
• 保留结构化锚点：搜索时指定上下文（如“在 标签内查找”），利用 DOM/XPath 定位后再对子树内容做轻量展平，缩小搜索范围。
• 预编译 + 边界感知分块：对固定模式使用 regexp.MustCompile，读取文件时预留前一块末尾 N 个字符（N ≥ 模式最大长度），避免跨块漏匹配。
• 用专用索引替代运行时展平：对高频搜索场景，提前构建 BM 或 Aho-Corasick 多模式自动机，并将原始文档按段落/句子切分后索引，而非等待查询时再拼接。
