用 response()->cookie() 设置 cookie 最可控，参数顺序为 name、value、minutes、path、domain，漏掉 minutes 会导致会话级失效；设 7 天需传 72460，path 要匹配部署路径，secure=true 需 https，httponly=true 则 js 不可读。
怎么用 response()->cookie() 设置 Cookie
直接在控制器里调用 response()->cookie() 是最常用也最可控的方式。它不依赖请求生命周期，也不受中间件顺序干扰，适合需要精确控制过期时间、作用域或 HttpOnly 的场景。
常见错误是传错参数顺序——这个函数前四个参数固定为：name、value、minutes、path，第五个才是 domain。漏掉 minutes 或传 null 会导致 Cookie 变成会话级（浏览器关闭即失效），而不是按预期持久化。
- 如果要设 7 天有效期：传
7 * 24 * 60，别写7 -
path默认是'/'，但如果你的 Laravel 应用部署在子路径（比如/app/），记得显式设成'/app/'，否则前端发请求时可能拿不到 - 设
secure => true时，确保当前是 HTTPS 环境，否则浏览器直接忽略该 Cookie
return response('OK')->cookie(
'tracking_id',
'abc123',
7 * 24 * 60,
'/',
null,
true,
true,
false,
'Lax'
);
为什么 Cookie::queue() 有时不生效
Cookie::queue() 是“延迟写入”，它把 Cookie 挂到响应栈里，等整个响应生成完毕才真正塞进去。好处是可以在中间件、视图甚至模型里随时加 Cookie；坏处是——如果响应已经提前发送（比如用了 dd()、触发了异常、或者用了流式响应），队列里的 Cookie 就永远发不出去。
另一个坑是默认作用域：它默认用 config('session.cookie_path') 和 config('session.domain')，和 session 配置强绑定。如果你改过 SESSION_DOMAIN 但没同步更新 cookie_domain，就可能出现本地能设、线上设不上。
- 检查是否在
App\Http\Middleware\EncryptCookies之前调用了queue()—— 这个中间件会加密 Cookie 值，但不会影响队列时机 - 调试时用
dd(response()->headers->getCookies())查看最终实际附带的 Cookie 列表，比抓包更快 - 避免在异步任务（如队列 Job）里用
Cookie::queue()—— 没有响应对象，根本无处可塞
前端 JS 能不能读到 Laravel 设的 Cookie
能不能读，取决于你设 Cookie 时传的 httpOnly 参数。Laravel 默认是 true，也就是说，JS 调用 document.cookie 是看不到的。这是安全设计，不是 bug。
如果你确实需要前端读（比如做轻量级用户偏好缓存），必须显式关掉：httpOnly => false。但要注意：一旦关了，这个 Cookie 就可能被 XSS 攻击窃取，别用来存敏感信息。
- 别为了“方便调试”全局关掉
httpOnly，只对明确需要 JS 访问的个别 Cookie 关 - 设
SameSite => 'Strict'或'Lax'后，跨站请求（比如从别的域名 iframe 里访问你的页面）可能收不到 Cookie，这和 JS 是否能读无关，是浏览器策略 - Chrome 98+ 对
SameSite=None强制要求Secure，所以如果设了SameSite=None却没配secure => true，Cookie 直接被丢弃
怎么在 API 响应里正确设置 Cookie
Laravel API 默认不启用 session，而 Cookie::queue() 在无 session 配置时行为不稳定。更稳妥的做法是绕过 Cookie 门面，直接操作响应头，尤其当你用 api 中间件组时。
API 场景下还要注意：移动端或某些 HTTP 客户端（比如 Flutter 的 http 包）对 Cookie 处理比较原始，不自动管理 Set-Cookie，得自己解析并带上后续请求。这时候不如考虑用 token 放 header，Cookie 反而增加兼容性负担。
- API 响应中设 Cookie，优先用
response()->withCookie()链式调用，别依赖Cookie::queue() - 确认
config/session.php里driver不是array（开发环境默认可能是），否则 Cookie 无法持久化 - 如果用 Sanctum 或 Passport，它们本身通过 Cookie + XSRF-TOKEN 配合工作，自定义 Cookie 名称别和
sanctum_token、XSRF-TOKEN冲突
复杂点在于：Cookie 不是“设了就完事”，它和 domain、path、协议、SameSite、客户端能力全绑在一起。一个参数不对，前端就收不到，还很难定位是哪一环断了。建议每次改完立刻用 curl 或 Postman 看响应头里的 Set-Cookie 字段原样输出，比靠浏览器开发者工具更可靠。
