Cookie 的 Path 属性仅控制浏览器自动发送该 Cookie 的路径范围，即只在指定路径及子路径的 HTTP 请求中携带，不提供脚本访问控制；限制 JS 访问需依赖 HttpOnly，而非 Path。
在 JavaScript 中，无法直接通过脚本设置 Cookie 的 Path 属性来限制“脚本访问权限”——因为浏览器对 Cookie 的读写控制是基于同源策略和 Cookie 自身的 Path、Domain、HttpOnly 等属性协同生效的，而 JS 只能读写当前路径满足条件且非 HttpOnly 的 Cookie。
Cookie 的 Path 作用是什么？
Path 是服务端设置 Cookie 时指定的一个属性，用于声明该 Cookie 在哪些 URL 路径下会被自动发送给服务器。它不控制前端 JavaScript 能否读取或修改 Cookie，只影响请求头中 Cookie 字段的自动携带行为。
例如：
- 服务端设置：
Set-Cookie: sessionid=abc123; Path=/admin - 那么浏览器在向
/admin/、/admin/users、/admin/api/data发起请求时，会自动带上这个 Cookie - 但向
/public或根路径/发起请求时，不会携带
JavaScript 能否读写指定 Path 的 Cookie？
不能精确控制。
立即学习“Java免费学习笔记（深入）”；
-
document.cookie只能读写当前页面 URL 路径满足 Path 条件且未标记HttpOnly的 Cookie - 比如当前页面是
https://example.com/admin/settings，它能读取Path=/admin的非 HttpOnly Cookie - 但你不能用 JS “主动指定 Path” 去读一个
Path=/api的 Cookie（即使当前 URL 包含/api），除非当前路径确实匹配该 Path - 同样，JS 设置 Cookie 时写的
Path=xxx只是告诉浏览器“这个 Cookie 应该在哪些路径下发送”，不是权限开关
如何真正限制脚本访问敏感 Cookie？
靠 HttpOnly，而不是 Path：
- 服务端设置 Cookie 时加上
HttpOnly标志（如Set-Cookie: auth_token=xxx; Path=/; HttpOnly） - 这样
document.cookie就完全读不到它，XSS 攻击也无法窃取 -
Path可配合HttpOnly使用，缩小服务端接收该 Cookie 的范围（比如只让/api接口收到 token），但它本身不防 JS 访问
实际设置示例（服务端视角更关键）
前端 JS 设置带 Path 的 Cookie（仅限非 HttpOnly）：
注意：这是客户端设置，通常不推荐用于敏感数据document.cookie = "theme=dark; Path=/dashboard; Max-Age=3600";
此时只有在 /dashboard 及其子路径（如 /dashboard/profile）下的页面才能通过 document.cookie 读到它（前提是没设 HttpOnly）。
