Go 文件路径安全库 filepath-securejoin 全解析：从 SecureJoin 到 pathrs-lite 的 API 演进与安全机制-平芜编程栈

Go 文件路径安全库 filepath-securejoin 全解析：从 SecureJoin 到 pathrs-lite 的 API 演进与安全机制

【免费下载链接】opencloud🌤️ OpenCloud is the open source platform for file management, sharing and collaboration. Simple and sovereign.项目地址: https://gitcode.com/GitHub_Trending/op/opencloud

导读

本文以 OpenCloud 仓库中 vendored 的github.com/cyphar/filepath-securejoin v0.6.1所附 CHANGELOG.md 为主线，结合 join.go、vfs.go、README.md 等源码，系统梳理这一在 Docker、runc、Kubernetes 等容器生态中被长期使用的事实标准路径安全库：它的设计动机、两代 API 模型、与openat2等内核原语的交互策略，以及从 0.1.0 到 0.6.1 的每一次安全修复与破坏性变更。读完本文，你将理解SecureJoin的 TOCTOU 局限为何无法根除、pathrs-lite新 API 采用何种句柄模型来彻底规避竞态，以及该库作为 OpenCloud 间接依赖（见 go.mod 第 184 行）在依赖树中扮演的角色。

1. 为什么需要"安全的 filepath.Join"

filepath-securejoin最初只是SecureJoin的一个实现——一个比filepath.Join更安全的路径拼接函数，其设计目标是限制路径查找必须落在指定的 root 目录之内（该想法曾被提议纳入 Go 标准库，对应 golang/go 议题 #20126）。它的实现脱胎于多个容器运行时中的既有代码，核心语义可以理解为用户态实现的chroot(2)：解析路径中的每一个符号链接时，都把它当作相对于 root 来解释，而不是相对于宿主机的根目录。

从 doc.go 的包文档可以看到它的定位——"让你能像把 rootfs 当作 chroot 一样解析 rootfs 内的路径"。该库被 Docker、runc、Kubernetes 等容器运行时使用了多年，事实上已成为"安全操作容器文件系统路径"的事实标准。

但 README 与 CHANGELOG 都反复强调一个关键事实：SecureJoin这个 API 在根本上是不安全的。它返回的是一个路径字符串，攻击者可以在函数返回之后、调用方真正使用该路径之前，把路径上的某个组件替换成符号链接，从而发起典型的TOCTOU（time-of-check to time-of-use）竞态攻击。正因如此，README 明确建议新用户不要使用SecureJoin，而应转向新 API 或 libpathrs（外部项目，此处仅作背景说明，不再展开）。

2. 旧 API：SecureJoin 与 SecureJoinVFS 的语义保证与实现

2.1 保证的四条语义

README 在承认上述局限的前提下，给出了旧 API 的精确保证：

若未返回错误，结果字符串必须是 root 的子路径，且不再包含任何符号链接路径分量（全部已被展开）；
展开符号链接时，所有链接目标都必须相对于 root 解析，即前面所说的 chroot 语义；注意输入路径不会先做词法清理（不调用filepath.Clean）；
不存在的路径分量不受影响（与filepath.EvalSymlinks的语义类似）；
返回路径始终经过filepath.Clean，因此不含..分量。

2.2 实现源码解析

在 join.go 中，SecureJoinVFS的核心是一个逐分量循环：

func SecureJoinVFS(root, unsafePath string, vfs VFS) (string, error) { // root 不得包含 ".." 分量，否则拼接子路径时会得到怪异路径 if hasDotDot(root) { return "", errUnsafeRoot } if vfs == nil { vfs = osVFS{} } unsafePath = filepath.FromSlash(unsafePath) var ( currentPath string remainingPath = unsafePath linksWalked int ) for remainingPath != "" { // ... 取出下一个路径分量 part ... nextPath := filepath.Join(string(filepath.Separator), currentPath, part) if nextPath == string(filepath.Separator) { currentPath = "" continue } fullPath := root + string(filepath.Separator) + nextPath // 判断该分量是否为符号链接 fi, err := vfs.Lstat(fullPath) if err != nil && !IsNotExist(err) { return "", err } if IsNotExist(err) || fi.Mode()&os.ModeSymlink == 0 { currentPath = nextPath continue } // 是符号链接：读取目标并前插到未解析路径前 linksWalked++ if linksWalked > consts.MaxSymlinkLimit { return "", &os.PathError{Op: "SecureJoin", Path: root + string(filepath.Separator) + unsafePath, Err: syscall.ELOOP} } dest, err := vfs.Readlink(fullPath) if err != nil { return "", err } remainingPath = dest + string(filepath.Separator) + remainingPath if filepath.IsAbs(dest) { // 绝对符号链接重置已做的工作 currentPath = "" } } finalPath := filepath.Join(string(filepath.Separator), currentPath) return filepath.Join(root, finalPath), nil }

算法要点：循环内用Lstat判断当前分量是否为符号链接；若是，则读取链接目标并将其前插到尚未解析的路径之前，绝对链接会重置currentPath；同时用linksWalked计数器防止符号链接环造成无限循环。SecureJoin只是SecureJoinVFS传入 nil VFS 的薄封装（见 join.go）。

2.3 VFS 接口：可测试性与自定义查找

VFS 接口只要求两个方法——Lstat与Readlink（语义与os.Lstat、os.Readlink一致）。nil VFS 等价于使用标准os.*系列函数。该接口是 0.2.0 版本随SecureJoinVFS一起引入的，最初目的有二：一是用于 mock 测试（0.2.0 借此实现了100% 测试覆盖率）；二是支持自定义查找逻辑，例如 rootless 容器场景——在没有CAP_DAC_READ_SEARCH/CAP_DAC_OVERRIDE能力时，需要特殊手段才能访问权限怪异的目录。

2.4 root 路径的 Clean 限制（0.4.0 / 0.4.1 的收紧与放宽）

0.4.0 是一个破坏性变更：SecureJoin(VFS)开始拒绝非filepath.Clean的 root 路径。理由很实际——传入形如/symlink/..的 root 时，SecureJoin得到的路径会被放到/下，而/symlink/..实际指向的可能是另一个目录。虽然这本质上是调用方责任，但移除这个"foot-gun"被认为是值得的（该问题最初由 Erik Sjölund 作为潜在安全问题上报）。

0.4.1 随即发现 0.4.0 的限制过严，导致用户升级时出现回归，因此放宽为：仅当 root 路径包含..分量时才报错。CHANGELOG 仍建议调用方对 root 使用filepath.Clean，甚至filepath.EvalSymlinks预先解析。

2.5 错误处理细节的演进

0.2.1：引入自有的IsNotExist实现，正确处理SecureJoin中的ENOTDIR（见 join.go，现在它同时识别os.ErrNotExist、ENOTDIR与ENOENT）；
0.2.2：符号链接环的基础错误改用syscall.ELOOP，而非内部自定义错误，使调用方可以更方便地用errors.Is判断；
0.2.3：改用 Go 1.13 风格的%w错误包装，从而移除了对github.com/pkg/errors的依赖；
0.2.5：修复符号链接环报错时引用的路径不正确的问题（#10），并微调了..、.等词法分量的处理（无行为变化）。

3. 新 API：基于 *os.File 的安全句柄模型

3.1 0.3.0：从 libpathrs 移植的句柄式 API

0.3.0 新增了一组从 libpathrs（外部项目）改编而来的、以*os.File为核心的 API。CHANGELOG 强烈建议优先使用它们，因为它们比SecureJoin提供强得多的攻击防护：

Open(at)InRoot：在 rootfs 内解析路径并返回指向该路径的*os.File。返回的句柄是O_PATH句柄——不能直接读写（详见 open(2)），这样设计是为了避免用户意外打开坏的 inode 造成 DoS，同时保留 PTY 派生等有用特性；
Reopen：接收O_PATH句柄，安全地"升级"为普通句柄（非O_PATH句柄也可用，但O_PATH是最典型场景）；
MkdirAll：os.MkdirAll的安全版本，可在 rootfs 内安全创建目录树；MkdirAllHandle则额外返回最终创建目录的*os.File句柄。

OpenatInRoot/MkdirAllHandle的 root 以*os.File形式传入，从而保证多次调用操作的是同一个 rootfs，避免路径字符串被竞态替换。

3.2 与 SecureJoin 的行为差异

README 特别强调一个行为差异：与SecureJoin不同，OpenInRoot/MkdirAll一旦遇到悬空符号链接或不存在路径会立即报错。SecureJoin会把不存在的分量当作真实目录继续处理、允许部分解析悬空链接——这违背 Linux 对不存在路径与悬空链接的处理方式，新 API 不再允许这种行为。这也意味着MkdirAll不会为悬空符号链接所指向的不存在的目录创建目录。

3.3 0.5.0：拆分为 pathrs-lite 子包并切换许可证

0.5.0 做了重大重组：0.3.0 引入的新 API 全部移入新子包pathrs-lite（即github.com/cyphar/filepath-securejoin/pathrs-lite）。拆分的目的是更清晰地区分新旧 API，并暗示该子包的定位——它是功能精简版、纯 Go 实现的 libpathrs。顶层包保留了一批过渡用 wrapper，但 CHANGELOG 明确声明这些 wrapper已废弃，将在下一个 minor 版本移除，用户应更新 import 路径。

同时，pathrs-lite子包改用Mozilla Public License version 2.0授权（详见 COPYING.md 及各文件的许可证头），整个项目的许可证标识为BSD-3-Clause AND MPL-2.0（见 README.md）。任何使用新 API 的项目都需要注意 MPL-2.0 的文件级许可证要求。

3.4 0.6.0：移除废弃 wrapper，引入 libpathrs 后端

0.6.0 兑现了 0.5.0 的承诺，移除了所有已废弃的MkdirAll、MkdirAllHandle、OpenInRoot、OpenatInRoot、Reopenwrapper，要求用户直接使用pathrs-lite。同时pathrs-lite新增对libpathrs 作为后端的支持：这是可选的，可在构建时用libpathrsbuild tag 启用。设计意图是让下游库能继续使用纯 Go 的pathrs-lite，而发行版/厂商可以在整个二进制中按需切换到 libpathrs 后端。

4. 与内核的交互：openat2 策略、缓存 bug 与 EAGAIN 重试

4.1 机会式使用新内核原语

README 说明新 API 的实现会机会式地使用更新的内核能力：

在足够新的内核（Linux 5.6+）上，所有查找操作使用openat2(2)，以限制 magic-links 与 bind-mount 穿越（针对部分操作），并利用RESOLVE_IN_ROOT在 rootfs 内高效解析符号链接；
对恶意/proc挂载提供加固：所有用户都受益于openat2(2)的防护，特权用户还会进一步受益于fsopen(2)与open_tree(2)（Linux 5.2+）。

4.2 决策缓存 bug 与 seccomp-bpf（0.6.1 / 0.5.2）

0.6.1 与 0.5.2（两个版本在同一天发布，修复内容一致）修复了一个隐蔽的问题：原先决定"使用openat2(2)还是回退到O_PATH解析器"的逻辑会缓存探测结果以避免无谓的测试运行。但当pathrs-lite被一个给自己施加新 seccomp-bpf 过滤器的程序使用时，若过滤器拒绝了openat2(2)，缓存会导致直接返回该错误而不是回退到O_PATH解析器。修复方案是：只在openat2(2)出错时缓存结果，成功时不再缓存。

同一版本还移除了openat2wrapper 中的一个文件描述符泄漏——该泄漏发生在为RESOLVE_IN_ROOT做必要的dup时。

4.3 EAGAIN 重试：从 32 次到 128 次（0.5.1）

0.5.1 处理了一个内核交互的现实问题：openat2(2)在检测到可能的攻击（典型场景是：带..分量的路径行走过程中发生 rename 或 mount）时会返回-EAGAIN，这是内核避免 DoS 的必要机制，但也要求用户态做重试循环。

旧版pathrs-lite会重试 32 次后返回错误，但用户报告在高负载系统上会触达该上限。CHANGELOG 记录了一个合成基准：在 16 核机器上让攻击者在每个核上都对文件做紧密循环 rename（最坏情况），runc 中出现了约3% 的失败率。改进有两方面：

重试上限提升到128 次——O_PATH解析器典型情况下的系统调用数量与之相当，不至于成为新的 DoS 向量；同样基准下失败率降到约0.12%；
同时返回可被调用方检测的unix.EAGAIN错误。对偶发错误更敏感的调用方可以自行实现无限EAGAIN重试循环，但 CHANGELOG强烈建议在重试循环中使用基于时间的截止期限，避免无界的拒绝服务。

4.4 内核版本相关的回退（0.5.0）

0.5.0 记录了一个兼容性细节：RHEL 8 内核反向移植了fsopen(2)，但测试中发现其存在非常糟糕且难以调试的性能问题，因此实现会显式拒绝在内核版本低于 5.2 时使用fsopen(2)，回退到open("/proc")。

5. 安全 /proc 访问：procfs.Handle API

5.1 0.5.0 导出安全 procfs API

0.5.0 将安全 procfs API 的大部分关键部分导出到github.com/cyphar/filepath-securejoin/pathrs-lite/procfs，核心是一个新的procfs.HandleAPI：

OpenProcRoot：返回/proc的安全句柄——尽可能使用subset=pid以防范误写攻击与泄漏，并用fsopen(2)避免挂载竞态；OpenUnsafeProcRoot则不尝试subset=pid，泄漏风险更高。大多数用户应使用OpenProcRoot（即便需要以ProcRoot作为操作基点，filepath-securejoin 也会在必要时内部打开一个句柄）；
(*procfs.Handle).Open*系列方法：为/proc内特定子路径获取安全的O_PATH句柄。对OpenThreadSelf，返回的ProcThreadSelfCloser必须在完全使用完句柄后调用——因为 Go 是多线程的，/proc/thread-self若不runtime.LockOSThread可能消失，ProcThreadSelfCloser目前等价于runtime.UnlockOSThread。注意：该 API 无法打开任何 procfs 符号链接（尤其是 magic-links），这是当前 filepath-securejoin 不支持的（libpathrs 支持）；
ProcSelfFdReadlink：获取文件描述符的内核路径表示（类似readlink("/proc/self/fd/...")），但会校验不存在能欺骗进程的刁钻 overmount。返回的字符串只是某一时刻的快照，攻击者可能移动被指向的文件；复杂命名空间配置也可能返回无意义路径。该值只能作为安全属性的次要验证，不能作为"某句柄对应某路径"的证明。

内部使用的 procfs 句柄与其余filepath-securejoin一致：对特权程序，通常是fsopen(2)创建的进程内私有 procfs 实例。该 API 被定位为迁移到 libpathrs 前的过渡方案——libpathrs 提供更全面、更健壮的安全 procfs API。

5.2 无 openat2 环境的加固与局限（0.5.0）

0.5.0 之前，加固版 procfs 实现只在三类环境下防 overmount 攻击：有openat2(2)（Linux 5.6）的系统；有fsopen(2)/open_tree(2)（Linux 5.2）且有权限使用它们的程序；其余用户则会被能创建恶意挂载的攻击者（多数系统上是 sysadmin）欺骗。由于该 API 现在要对外导出，继续宣称"安全"却不防已知攻击是不明智的，因此 0.5.0 补强了缺乏上述保护时 procfs API 的防护。

但 CHANGELOG 也坦承这些防护的边界：最全面的防护依赖statx(STATX_MNT_ID)（Linux 5.8）；更老的内核上没有有效防护（仅对非 procfs 文件系统分量有少量保护，足够聪明的攻击者可以绕过）；且STATX_MNT_ID易受挂载 ID 复用攻击，STATX_MNT_ID_UNIQUE（Linux 6.8）可缓解但会提高最低内核版本要求。这些防护有限却需要大量额外代码，正是当初没有在 filepath-securejoin 中实现它们的主要原因之一。

6. MkdirAll 系列 API 的细节演进

CHANGELOG 用多个版本持续打磨MkdirAll，值得单独梳理：

0.3.2：向MkdirAllInRoot传入S_ISUID/S_ISGID位时返回显式错误，说明这些位会被mkdirat(2)静默忽略（man page 已明确该行为）。虽然静默忽略最兼容，但显式报错能避免用户误以为代码设置了这些位；需要兼容的程序可以自行掩掉这些位（#23、#25）。同版本修复了S_ISGID目录下子目录继承问题——有S_ISGID的目录创建子目录时也会带S_ISGID，且新 inode 会使用不同 gid，旧版"期望的 owner 与 mode"校验未正确处理（#24、#25）；
0.3.3：移除MkdirAll中的 mode 与 owner 校验逻辑（原本防御一些理论攻击，但实际不带来收益，反而在更复杂的文件系统布局下引发偶发错误）；同时移除"创建的目录必须为空"的检查——cgroup等伪文件系统会创建非空目录，旧逻辑会判错；
0.3.5：修复两个进程竞态创建同一目录时返回EEXIST的问题——现在仍会校验该路径是目录，但不再产生虚假错误（对应 opencontainers/runc#4543 场景）；
0.4.0：MkdirAll/MkdirHandle的模式参数从裸的unix.S_*风格改为os.FileMode风格，可能带来编译期类型错误。大部分用户行为不变（两者底部的0o777位相同），但若用unix.S_ISVTX设置 sticky bit，必须改用os.ModeSticky，否则运行时会报错；unix.S_ISUID/unix.S_ISGID现在被当作非法位处理（此前传入这些位同样是错误，只是错误信息不同）。

此外，0.3.1 中Open(at)InRoot可以跳过MkdirAll的"部分查找"额外工作，大幅减少了两种实现的底层操作次数（openat2路径呈多倍下降），并使行为更严格地对齐openat2(RESOLVE_IN_ROOT)；同时尽可能改用readlinkat(fd, "")，避免 rename 竞态期间的偶发错误，并理论上防止 mount 攻击在 magic-link readlink 时欺骗加固的 procfs 处理器（Reopen仍可能受这类攻击影响）。

7. 兼容性与安全公告

7.1 Windows 安全修复（0.2.4）

0.2.4 修复了 filepath-securejoin 在 Windows 上使用时的一个潜在安全问题（GHSA-6xv5-86q9-7xr8）：某些情况下可能生成 rootfs 之外的路径；同时改善了带卷名（volume name）的 Windows 路径处理。此版本起 CI 迁移到 GitHub Actions，得以覆盖 Windows、Linux 与 macOS 三平台测试。相关处理逻辑在源码中也有体现——stripVolume会剥离路径中的 Windows 卷名（Linux 上被编译器优化为 no-op），hasDotDot会先剥离卷字母再检测..分量（见 join.go）。

7.2 Go 版本要求（0.3.6）

0.3.6 将最低 Go 版本要求降回Go 1.18（内部使用泛型）。背景是 0.3.0 把要求"任意地"提到了 1.21，导致部分下游在给旧分支 backport 修复时不得不做变通；虽然上游早已不再支持 Go ≤1.21，但使用本库仍比手工变通更好。同版本还把golang.org/x/sys的最低要求降到v0.18.0（需要fsconfig(2)的 wrapper），同样便于 backport。

7.3 测试与质量里程碑

0.1.0（2017-07-19，首个发布）：完整实现，覆盖率 93.5%（缺失的仅是难以 mock 的错误分支）；
0.2.0（2017-07-19）：100% 测试覆盖率，并随SecureJoinVFS引入 VFS mock 测试能力。

8. 在 OpenCloud 项目中的角色

OpenCloud 仓库在 go.mod 第 184 行声明了github.com/cyphar/filepath-securejoin v0.6.1 // indirect——即它目前是作为间接依赖被引入的（由其他直接依赖传递带入），仓库使用 Go modules 的 vendor 机制把完整源码固定在 vendor/github.com/cyphar/filepath-securejoin 目录下，包括：

CHANGELOG.md：本文主线的完整版本历史；
README.md：新旧两代 API 的权威使用说明；
doc.go：包级文档与设计定位；
join.go / vfs.go：旧 API 的核心实现；
COPYING.md、LICENSE.BSD、LICENSE.MPL-2.0：双许可证文本；
VERSION文件内容为0.6.1，与 go.mod 锁定版本一致。

对 OpenCloud 这类需要处理文件存储与共享路径的服务而言，路径拼接安全直接关系到底层文件系统的隔离边界——把用户可控路径安全地解析到存储根目录之内，正是该库的核心价值。从 CHANGELOG 的时间线可以看到，OpenCloud 锁定在 0.6.1，恰好包含了 0.5.2/0.6.1 的 seccomp 缓存修复与 FD 泄漏修复、0.5.1 的 EAGAIN 重试改进等全部安全更新。

9. 版本演进时间线速览

版本	日期	关键变化
0.1.0	2017-07-19	首个发布，覆盖率 93.5%
0.2.0	2017-07-19	100% 测试覆盖率；新增`SecureJoinVFS`与 VFS mock 接口
0.2.1	2018-09-05	自有`IsNotExist`，正确处理`ENOTDIR`
0.2.2	2018-09-05	符号链接环改用`syscall.ELOOP`，便于`errors.Is`
0.2.3	2021-06-04	改用 Go 1.13`%w`错误包装，移除 pkg/errors 依赖
0.2.4	2023-09-06	修复 Windows 路径逃逸（GHSA-6xv5-86q9-7xr8）；CI 覆盖三平台
0.2.5	2024-05-03	修复符号链接环报错路径；词法分量处理微调
0.3.0	2024-07-11	新增`Open(at)InRoot`/`Reopen`/`MkdirAll`句柄式 API
0.3.1	2024-07-23	优化部分查找；改用`readlinkat(fd, "")`
0.3.2	2024-09-13	`S_ISUID`/`S_ISGID`显式报错；修复`S_ISGID`继承
0.3.3	2024-09-30	移除 mode/owner 校验与"空目录"检查
0.3.4	2024-10-09	修复非测试代码中`import "testing"`的问题（#32）
0.3.5	2024-12-06	修复`MkdirAll`竞态`EEXIST`（runc#4543）
0.3.6	2024-12-17	最低 Go 版本降到 1.18；x/sys 降到 v0.18.0
0.4.0	2025-01-13	`SecureJoin`拒绝非 Clean 的 root；`MkdirAll`改用`os.FileMode`（破坏性）
0.4.1	2025-01-28	放宽 root 限制：仅含`..`分量时报错
0.5.0	2025-09-26	新 API 移入`pathrs-lite`（MPL-2.0）；导出 procfs 安全 API；RHEL8 fsopen 回退（破坏性）
0.5.1	2025-10-31	EAGAIN 重试上限 32 → 128，并向上返回`unix.EAGAIN`
0.5.2	2025-11-19	修复 openat2 决策缓存与 seccomp-bpf 冲突；修复 FD 泄漏
0.6.0	2025-11-03	移除全部废弃 wrapper；`pathrs-lite`支持 libpathrs 后端（破坏性）
0.6.1	2025-11-19	与 0.5.2 相同的缓存/FD 修复（0.6 分支）

10. 迁移与最佳实践

综合 CHANGELOG 与 README 的建议，使用或迁移到 filepath-securejoin 时应遵循：

新项目直接用新 API：使用pathrs-lite的OpenInRoot/MkdirAll等句柄式 API（或直接迁移到 libpathrs）；不要再用存在 TOCTOU 问题的SecureJoin；
关注破坏性变更窗口：0.5.0 已把新 API 移入pathrs-lite子包并改 MPL-2.0 授权；0.6.0 已移除顶层废弃 wrapper。仍在用 0.4.x 旧包装函数的代码需要更新 import 路径并评估许可证影响；
root 路径必须干净：给SecureJoin/OpenInRoot传入的 root 应经过filepath.Clean（最好filepath.EvalSymlinks），且绝不能由攻击者控制；0.4.0+ 会直接拒绝含..的 root；
处理 EAGAIN：对openat2场景，调用方应能识别unix.EAGAIN并重试，重试循环务必使用时间截止期限而非无限重试，避免 DoS；
注意内核版本差异：RESOLVE_IN_ROOT（5.6）、fsopen/open_tree（5.2）、statx(STATX_MNT_ID)（5.8）等防护能力随内核版本浮动，老内核上安全收益有限，需评估部署环境；
尊重双许可证：新 API（pathrs-lite）相关文件按 MPL-2.0 授权，旧 API 按 BSD-3-Clause 授权，使用前核对各文件许可证头与 COPYING.md。

结语

从 2017 年的SecureJoin到 2025 年的pathrs-lite与 libpathrs 后端，filepath-securejoin 的演进史实际上是一部"如何在用户态对抗文件系统竞态攻击"的技术史：它从"返回一个安全路径字符串"的旧模型，走向"返回安全文件句柄"的新模型；从纯粹的用户态解析，走向与openat2、fsopen、statx等内核原语的深度协作。CHANGELOG 中每一处看似琐碎的修复（缓存策略、重试上限、模式位校验）背后，都是容器运行时在真实攻击与真实负载下暴露出的边界问题。对于 OpenCloud 这类依赖 vendored 依赖树保证可复现构建的 Go 服务而言，理解这份 CHANGELOG，就是在理解自己供应链中一段关键安全代码的每一处取舍。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Go 文件路径安全库 filepath-securejoin 全解析：从 SecureJoin 到 pathrs-lite 的 API 演进与安全机制