概览
解析原始 Set-Cookie 响应头，展示实际属性，并标记 SameSite、Secure、Path、HttpOnly 等常见配置问题。
Parse raw Set-Cookie lines, expose effective attributes, and flag browser behaviors that commonly break auth and session flows.
如果省略 `Path`，浏览器会根据设置这个 Cookie 的请求 URL 推导默认路径。这种默认行为很容易被忽视，最终导致 Cookie 只在比团队预期更少的路由下可用。显式写出 `Path=/` 或其他有意图的范围，通常会更清晰，也更容易排查。
Supporting guides that connect this tool to the broader category workflow.
当登录后的认证 Cookie 看似“消失”时，这份指南帮助你区分后端响应成功与浏览器 Cookie 策略拒收之间的差别。
帮助你区分请求格式错误、认证失败、权限不足和校验失败，避免团队在 API 排障时修错方向。
从浏览器执行规则出发，解释为什么当前端发送 cookies 或带凭证请求时，`Access-Control-Allow-Origin: *` 会直接触发 CORS 阻止。
通过真实场景解释何时应编码完整 URL，何时应只编码单个参数或嵌套值。
是什么
Set-Cookie 头检查器的重点，不是看后端“打算”怎么设置 Cookie，而是帮助你理解浏览器最终会怎么解释它。很多 Cookie 故障并不是接口没返回，而是少了一个属性、误用了默认 Path，或者跨站策略组合只在真实部署环境里才暴露问题。
把每一行 `Set-Cookie` 拆成清晰的属性视图，再附上高价值警告之后，认证和会话问题的排查速度会快很多，尤其适合前后端联调、事故复盘和本地环境验证。
如何使用
把日志或浏览器开发者工具里看到的 `Set-Cookie` 响应头逐行粘贴进来。工具会把 Cookie 名称和值与属性分开显示，并标记典型问题，例如 `SameSite=None` 却没有 `Secure`、缺少 `Path`、看起来像会话 Cookie 却没有 `HttpOnly` 等。
使用示例
示例:
输入: `refresh_token=def456; Path=/auth; HttpOnly; SameSite=None`
工具会指出：这个 Cookie 使用了 `SameSite=None`，但没有声明 `Secure`。在现代浏览器里，这通常会导致跨站上下文中的 Cookie 被拒收。表面上看后端响应是正常的，但登录流程里 Cookie 实际并没有成功落地。常见使用场景
1. 排查为什么登录 Cookie 出现在响应里，却没有进入浏览器存储。
2. 在上线新的会话策略前审查认证 Cookie 配置。
3. 对比 staging 和 production 中跨站 redirect 场景下的响应头差异。
4. 向团队解释 `Path`、`SameSite`、`Secure`、`HttpOnly` 在真实浏览器里的影响。
常见问题