不能直接用 implode(" > ", $path)，因为未过滤的用户输入会导致XSS、HTML结构破坏、SQL注入及缩进错乱；安全做法是递归中逐层htmlspecialchars净化，仅用于展示，数据库只存id和parent_id。
直接拼接字符串生成层级路径（比如用 " > " 连接）很容易在节点名称含特殊字符时出错，更危险的是如果数据来自用户输入且未过滤，可能注入 XSS 或破坏 HTML 结构。安全拼接的关键不是“怎么连”，而是“在哪连、连什么、连完怎么用”。
为什么不能直接用 implode(" > ", $path)？
常见错误是把原始 $node['name'] 直接拼进路径字符串，再原样输出到 HTML：
→ 如果某分类名是 <script>alert(1)</script>，拼出来就是可执行代码
→ 如果某名称含换行或制表符，缩进逻辑会错乱
→ 拼接后若用于 SQL 查询（比如按路径模糊搜索），还可能触发注入
- 拼接动作必须发生在数据已净化之后，而不是在原始数组上操作
- 路径字符串只应作为展示用途，不参与业务逻辑判断（如权限校验、路由匹配）
- 若需用于前端下拉选项的
value，应单独用id字段，而非路径文本
buildPath() 函数必须做三件事
一个安全的路径生成函数，不能只负责连接，还要承担净化与上下文适配责任：
- 递归向上查找时，每层都调用
htmlspecialchars($name, ENT_QUOTES, 'UTF-8')处理名称，确保输出到 HTML 安全 - 使用
str_repeat(" ", $level)（全角空格）或 CSStext-indent实现视觉缩进，避免用空格数控制——因字体渲染差异导致对齐失效 - 返回值明确区分用途：带 HTML 实体的字符串仅用于
<option>的label，不用于value或数据库写入
数据库里存 tree_path 字段反而更危险
有些方案提前把路径（如 "0,1,5" 或 "家电/电视/曲面电视"）存进数据库，看似省事，实则埋雷：
立即学习“PHP免费学习笔记（深入）”；
- 父节点重命名时，所有子节点的
tree_path都得批量更新，事务复杂且易漏 - 路径字段一旦被用户可控输入污染（比如通过 API 提交），整个树结构就不可信
- MySQL 中用
FIND_IN_SET()或LIKE '0,1,%'查询路径，无法走索引，大数据量时性能骤降
真正安全的做法是：只存 id 和 parent_id，路径在读取时实时生成、实时转义、用完即弃。
容易被忽略的边界点：空格、零宽字符、BOM
即使做了 htmlspecialchars()，仍可能因编码问题出错：
- 从 Excel 或 CMS 后台导入的分类名常带不可见的零宽空格（
\u200B），拼接后肉眼难查但破坏字符串比较 - 某些编辑器保存 UTF-8 文件时带 BOM，导致
json_decode()后的字符串开头多出\xEF\xBB\xBF - 用
trim()清洗名称时，要加ENT_QUOTES参数并指定编码，否则中文引号不被清理
最稳妥的方式是：在递归入口处统一清洗原始数据，而不是在每一层拼接时临时处理。
