Cookie 的 path 属性仅控制浏览器自动携带的路径前缀匹配，非权限校验机制；path=/admin 会错误匹配 /admin-api，应使用 path=/admin/ 等显式尾斜杠实现安全隔离。
Cookie 的 path 属性不能“控制访问权限”，它只决定浏览器在哪些请求路径下自动带上该 Cookie；真正的权限校验必须由服务端完成，path 只是前端可见性过滤器。
为什么 path=/admin 会匹配 /admin-api？
因为 path 是前缀匹配，不是目录级或完整路径匹配。浏览器只要发现当前请求路径以 path 值开头（且后跟 / 或路径结束），就发送 Cookie。
-
Set-Cookie: token=abc; path=/admin→ 会随/admin、/admin/、/admin/user、/admin-api（⚠️危险！）等请求发出 -
Set-Cookie: token=abc; path=/admin/→ 只匹配/admin/及其子路径（如/admin/users），不匹配/admin（无尾斜杠）或/admin-api - 要真正隔离管理后台，必须显式加尾斜杠：
path=/admin/，而非path=/admin
如何让 Cookie 全局可用或限定到单页？
全局可用需设为根路径；单页隔离则依赖精确路径 + 尾斜杠策略。
- 全站共享：设置
path=/（注意：这是默认值的显式写法，推荐始终明确写出） - 仅限某个页面（如
/login）：设path=/login，但注意这也会匹配/login-2—— 实际上无法靠path精确限定单页，应改用服务端逻辑或不同 Cookie 名区分 - 仅限某 SPA 子路由（如
/dashboard/*）：设path=/dashboard/，并确保所有相关 API 请求路径都落在该前缀下
常见配置错误与安全后果
仅靠 path 隔离，极易因路径设计松散导致敏感 Cookie 泄露。
立即学习“前端免费学习笔记（深入）”；
- ❌
path=/user用于用户数据 Cookie → 可能被/users、/user-profile、/user-api等路径意外携带 - ✅ 正确做法：按功能域划分，统一加尾斜杠 ——
path=/user/、path=/api/、path=/static/ - ⚠️
path不防 XSS：即使设了path=/admin/，攻击者仍可在该路径下通过 JS 读取document.cookie（除非加HttpOnly） - ⚠️
path不防 CSRF：它不阻止跨站请求携带合法 Cookie，必须配合SameSite和服务端 referer/token 校验
调试时怎么确认 path 生效了？
别只看设置语句，要验证实际请求头中 Cookie 是否出现。
- 打开浏览器 DevTools → Application → Cookies，检查对应 Cookie 的
Path列值是否为你设置的（如/admin/） - 分别访问
/admin/和/public/页面，在 Network → Headers → Request Headers 中查看Cookie:字段是否含目标 Cookie - 用
curl模拟验证：curl -I -b "session=123" https://example.com/admin/uservscurl -I -b "session=123" https://example.com/api/auth
最易被忽略的一点：path 的作用完全由浏览器执行，服务端无法感知或强制约束；一旦路径匹配规则被绕过（比如服务端路径解析不一致、反向代理重写 URL），path 隔离就会失效。所以它永远只是第一道轻量过滤，不是权限边界。
