PHP原生setcookie()默认不安全，因其不启用HttpOnly、Secure、SameSite等关键安全标识，易导致XSS窃取、中间人劫持及CSRF攻击；使用symfony/http-foundation可强制显式配置，但需手动集成到响应流程并严格校验五项参数。
单纯用 Composer 引入某个“Cookie 组件”不能解决 Cookie 安全操作问题——安全取决于你怎么设置参数，而不是用没用某个包。
为什么 setcookie() 默认不安全？
PHP 原生 setcookie() 默认不启用关键安全标识，比如 HttpOnly、Secure、Samesite。浏览器收到未标记的 Cookie，就可能被 XSS 窃取，或在跨站请求中被意外发送。
-
HttpOnly缺失 → JavaScript 可读（document.cookie），XSS 时极易泄露 session_id -
Secure缺失 → HTTP 协议下也发送，中间人可截获 -
Samesite缺失（尤其Lax或Strict）→ CSRF 风险显著升高
用 symfony/http-foundation 的 Cookie 类真能改善吗？
可以，但它不是“自动安全”，而是把安全参数显式化、不可绕过。它强制你思考每个选项，避免漏设。
- 构造
Cookie实例时，$httpOnly、$secure、$sameSite全是明确参数，没有默认“开”或“关”的模糊地带 - 必须传
$path和$domain，防止因路径宽松导致越权共享 - 示例：
$cookie = Cookie::create('session_id', $value, 3600, '/', '.example.com', true, true, false, 'Lax');这里true, true, false分别对应httpOnly、secure、raw，顺序容易错，建议用命名参数（PHP 8.0+）或常量代替布尔字面量
Composer 引入后仍要手动集成到响应流程
装了 symfony/http-foundation 不等于 Cookie 就变安全了。你得把它实际塞进响应头里：
- 不能只 new 一个
Cookie对象就完事——必须调用Response::withCookie()或Response::headers->setCookie() - 如果项目用的是原生 PHP 输出、或框架（如 Laravel）已封装响应逻辑，直接 new Cookie 可能被忽略，需查清该框架的 Cookie 注入机制
- 注意时区和时间戳：
expires参数必须是 Unix 时间戳（秒级），传字符串或 DateTime 对象会静默失败或设为会话 Cookie
真正麻烦的不是引入组件，而是每次设置 Cookie 时都得确认这五个值：name、value、expires、path、SameSite，缺一不可。漏掉 Samesite=Lax 在现代浏览器里可能直接被降级为 None 并拒绝发送。
