Go filepath.IsLocal 怎样判断路径是否局部安全

filepath.IsLocal 判断的是路径字符串是否具有词法局部性：输入非空、不是绝对路径，且在词法整理后不超出其求值目录；Windows 上还会排除特定保留名称。返回 true 不代表文件存在、权限正确，也不代表经过符号链接解析后仍在指定目录内。

因此，题目里的“局部安全”只能理解为这一有限的字符串边界。处理导入文件名时，可以先对原始输入调用 IsLocal，通过后再 Clean 和 Join；不能把结果当作可直接打开或删除文件的完整授权。下文示例只处理字符串，未执行文件操作或代码测试。

保留原始路径，再确定输入语义

先分清收到的是操作系统本地路径、URL 路径，还是某个跨平台存储协议中的名称。filepath 使用运行平台的路径规则，不负责 URL 解码，也不是跨平台文件名合法性检查器。这里限定为已经完成上层输入解析、准备作为本机相对路径使用的字符串。

保留原始输入用于判断。特别是空字符串：Clean 会把它整理为点号，若先 Clean 再 IsLocal，就可能把“未提供名称”变成“当前目录”。业务若不接受空值，应在语义改变前拒绝，而不是让后续默认行为替用户选目录。

不要为图方便先删除所有点号、替换路径片段或给输入强行加一个根分隔符。那会改变输入含义，使“原来是否局部”这个问题丢失。需要归一化时，先明确哪一层负责解码，并在最终被使用的路径语义上实施判断。

用 IsLocal 区分局部路径与越界路径

可把判断条件分为三个正文节点：非空条件、非绝对条件、目录范围；在 Windows 上另外考虑保留名称。原始路径交给 IsLocal，布尔结论表示这些词法约束是否满足，不涉及磁盘读取。Go 官方 IsLocal 文档明确强调它只进行词法分析。

表格是依据契约解释的预期，不是本机运行记录。只有“不是绝对路径”仍然不够：父目录相对名称也可能超出基准目录。反过来，字符串出现两个点也不代表一定有问题，memo..txt 与独立的父目录路径片段不是一回事。

校验通过后才整理并拼接路径

最小封装应让名字也表达范围。这里用 lexicalName，而不是 safeOpen：函数仅生成词法局部名称，并为当前业务额外拒绝点号。调用方再把受控 base 与返回名称拼接，仍不执行文件操作。

package main

import (
    "fmt"
    "path/filepath"
)

// lexicalName 仅生成词法局部名称，不访问文件系统，也不保证打开安全。
func lexicalName(name string) (string, error) {
    // 必须先判断原始输入，避免空字符串被 Clean 变成当前目录。
    if !filepath.IsLocal(name) {
        return "", fmt.Errorf("路径不是词法局部路径")
    }
    local := filepath.Clean(name)
    // 本示例业务只接收文件名称，额外拒绝指向基准目录本身。
    if local == "." {
        return "", fmt.Errorf("需要文件名称，不能使用基准目录")
    }
    return local, nil
}

func main() {
    // base 来自可信配置；本例只打印字符串，不执行打开、写入或删除。
    base := filepath.Join("workspace", "imports")
    names := []string{"", ".", "report.csv", "draft/../report.csv", "../report.csv"}
    for _, name := range names {
        local, err := lexicalName(name)
        if err != nil {
            fmt.Printf("%q: 拒绝 (%v)\n", name, err)
            continue
        }
        // 拼接只表达词法归属，不是符号链接或权限检查。
        joined := filepath.Join(base, local)
        fmt.Printf("%q: 词法路径 %q\n", name, joined)
    }
}

逐项阅读时应得到：空输入拒绝；点号虽被 IsLocal 接受，但因本例业务要求文件名称而拒绝；report.csv 与 draft/../report.csv 可得到相同的清理后名称；父目录开头的输入拒绝。这里接受可抵消片段是 IsLocal 的词法语义，不表示允许任意文件操作。

如果业务要求输入本身必须已经规范化，可另行要求原始字符串与 Clean 结果一致；那是更严格的命名策略，不要反过来声称 IsLocal 自身会拒绝所有可清理片段。不同原始路径映射到同一个整理后名称，也意味着存储键可能碰撞，需要由业务决定是否覆盖。

保存的是词法结果，不是安全凭证

清理后名称、可信基准目录、Join 和拼接路径构成字符串层的组合关系。IsLocal 为 true 时，官方给出的保证包括：Join(base, name) 在词法上位于 base 范围内，Clean(name) 不带根且不含父目录路径元素。

这项保证不读取实际文件系统。假如名称中的某级目录是符号链接，真实目标可能与字符串层的目录归属不同。因此，不能把 IsLocal 的布尔值存成“文件已安全”的长期凭证；后续查询、打开、写入和删除仍是另一类操作。

本篇不展开符号链接处理或文件系统隔离实现。需要此类保证时应选择与实际平台、操作及并发条件相匹配的文件访问方案，而不是给字符串判断加一个“绝对安全”的注释。还要注意，Windows 与 Unix 对分隔符和保留名称的规则并不相同。

把拒绝、查找和清理责任分开

输入拒绝、名称存储与实际访问应保留不同的状态。词法不局部时返回输入错误；通过后保存业务需要的相对名称，不把用户输入升级成受信任根目录；实际访问失败则记录相应错误，不回退到一个未经检查的原始名称。

清理策略也应沿用这个边界：删除不能仅凭“数据库里曾记录过 IsLocal=true”就视为安全。日志和审计可以区分原始名称与整理后名称，但避免泄露内部基准目录和敏感文件信息。本文代码刻意不包含删除或写入逻辑，防止把演示性的 Join 当成完整访问控制。

为什么点号会返回 true？

点号表示求值目录本身，并没有离开该目录。是否允许它作为业务文件名，是应用额外决定的条件。

能只用 IsAbs 取反吗？

不能。相对路径仍可能包含需要离开目录的父目录片段，也可能为空；非绝对只是局部性的部分条件。

能把 Unix 上的判断结果直接用于 Windows 吗？

不应如此假设。判断采用当前平台规则，应在实际消费路径的平台和语义上处理。

使用顺序可概括为：保留原始语义、判断词法局部性、施加业务命名约束，再构造路径字符串。真正访问文件时，另外承担文件系统层的安全责任。