优先用 preg_replace 配合正则排除 html 标签和属性值，对关键词转义后批量匹配替换；sql 层不可行，应交由视图层处理；推荐使用获取器 gethighlightcontentattr 实现高亮，避免污染原始数据。
ThinkPHP 模型搜索结果中怎么给关键词加 <em></em> 包裹
直接在查询后对字段内容做字符串替换就行，但必须避开 HTML 标签、属性值和已存在的高亮标记，否则会破坏结构或重复包裹。
常见错误是用 str_replace 粗暴替换，导致 <div class="title">PHP</div> 里的 PHP 被误包成 <div class="<em>PHP</em>">，页面直接崩。
<ul>
<li>优先用正则匹配「纯文本区域」：用 <code>preg_replace 配合 (?，排除引号包围的上下文
+、.），先用 preg_quote($keyword, '/') 转义preg_replace，改用数组批量匹配，避免嵌套高亮：preg_replace('/(' . implode('|', $escapedKeywords) . ')/i', '<em>$1</em>', $text)
ThinkPHP 查询时能直接在 SQL 里高亮吗
不能。MySQL 不支持运行时把字段值中的子串自动替换成带 HTML 标签的字符串——REPLACE() 只能换纯文本，且无法识别词边界，更没法防标签污染。
有人试过用 CONCAT + LOCATE 拼接 <em></em>，但一来逻辑爆炸，二来结果仍是字符串，PHP 层还得再解析一遍，反而更慢更脆。
- SQL 层只负责查出原始数据，高亮是视图层职责，强行塞进查询违背关注点分离
- 万一字段内容本身含
<em></em>，SQL 拼接会雪上加霜 - 分页场景下，SQL 层高亮还可能导致
COUNT(*)和实际渲染行数不一致
模型的 afterFind 或 append 属性能用来做高亮吗
可以，但要小心执行时机和范围。ThinkPHP 的 append 是在模型转数组后追加字段，而 afterFind 回调在单条数据查出后触发，两者都适合做高亮处理。
典型陷阱是：在 afterFind 里直接改 $this->content，会导致后续调用 save() 时把带 <em></em> 的 HTML 写回数据库。
- 推荐做法：定义一个只读的获取器（accessor），比如
getHighlightContentAttr，内部做高亮，调用时用$model->highlight_content - 如果必须塞进原字段，先备份原始值：
$this->origin_content = $this->content，再覆盖，避免污染持久化数据 - 注意 XSS：高亮前确保关键词和字段内容都已过滤或转义，别让用户输入的
<script></script>借壳混入
为什么用 <em></em> 而不是 <span class="highlight"></span>
因为 <em></em> 语义正确、零样式侵入、兼容性好。搜索引擎和读屏软件知道这是强调内容，而自定义 <span></span> 需额外 CSS 支持，上线漏了样式就白忙。
有人为“统一主题色”硬上 class，结果在后台接口、Excel 导出、API 返回里也混进了 <span></span>，下游系统直接报错解析失败。
- 前端需要不同样式？用 CSS 选中
em即可：em { background: #ffeb3b; font-style: normal; } - API 场景需纯文本？高亮函数加个
$returnHtml = true参数开关，关掉就只返回关键词位置数组，不插标签 - 移动端 WebView 对
<em></em>渲染更稳，老版本 Android 系统对自定义标签支持差
高亮本身很简单，难的是控制它不出现在不该出现的地方——比如数据库、日志、缓存键、导出文件。每次加完记得 grep 一下 <em></em> 出现的位置，比写一百行高亮逻辑都管用。
