当将 Cookie 域从 mydomain.com 升级为 .mydomain.com 后，旧 Cookie 未被清除，导致请求头中出现两个同名 Cookie；PHP 的 $_COOKIE 仅取首个（顺序不确定），引发值误读。本文提供可靠清除方案与最佳实践。
当将 cookie 域从 `mydomain.com` 升级为 `.mydomain.com` 后，旧 cookie 未被清除，导致请求头中出现两个同名 cookie；php 的 `$_cookie` 仅取首个（顺序不确定），引发值误读。本文提供可靠清除方案与最佳实践。
在 Web 开发中，Cookie 域名变更（如从 mydomain.com 改为 .mydomain.com）是常见优化操作，旨在支持子域名共享认证状态。但该操作存在一个易被忽视的关键陷阱：浏览器不会自动删除旧域下的同名 Cookie。结果是，客户端同时持有两条 Set-Cookie 指令生成的 Cookie：
cookieName=old_value; Domain=mydomain.com; Path=/cookieName=new_value; Domain=.mydomain.com; Path=/
由于 HTTP Cookie 头中同名 Cookie 以分号分隔、无强制顺序保证，服务器收到的 Cookie: 请求头可能为：
Cookie: cookieName=old_value; cookieName=new_value
或相反。而 PHP 的 $_COOKIE 机制仅保留第一个解析到的值（依据 RFC 6265，服务器应按顺序处理，但 PHP 实现取首项），导致业务逻辑始终读取到过期或错误的值。
✅ 正确解决方案：主动清除旧 Cookie
必须显式覆盖旧 Cookie，将其过期时间设为过去（如 Unix 时间戳 1），并严格匹配其原始属性（尤其是 Domain 和 Path）。否则，因属性不一致，浏览器会视其为不同 Cookie，无法覆盖。
以下为推荐清除代码（需在应用初始化或登录/配置更新等关键路径执行）：
// 清除旧 Cookie：Domain = 'mydomain.com'，Path = '/'
setcookie('cookieName', '', [
'expires' => 1,
'path' => '/',
'domain' => 'mydomain.com',
'secure' => false, // 与原设置一致
'httponly'=> true, // 与原设置一致
'samesite'=> '' // 若原为 null，此处留空或省略
]);
// 可选：立即刷新新 Cookie（确保新版生效）
setcookie('cookieName', 'new_value', [
'expires' => time() + 3600,
'path' => '/',
'domain' => '.mydomain.com',
'secure' => false,
'httponly'=> true,
'samesite'=> 'Lax'
]);⚠️ 关键注意事项：
-
Path必须精确匹配：/admin下设置的 Cookie 无法通过/路径清除；若旧 Cookie 的Path是/api，清除时也必须指定'path' => '/api'。 -
Domain区分大小写与格式：mydomain.com≠.mydomain.com；清除旧 Cookie 时不可误写为.mydomain.com。 -
协议一致性：若原 Cookie 在 HTTPS 站点设置且
secure=true，清除时也需保持'secure' => true，否则可能失败。 - 客户端缓存影响：清除指令需随响应返回，建议在用户首次访问新配置页面时触发（如首页、登录后重定向页），避免依赖用户手动刷新。
? 进阶建议：
- 部署前，在测试环境模拟双 Cookie 场景，用浏览器开发者工具 → Application → Cookies 验证清除效果；
- 对关键认证 Cookie（如
session_id），可增加服务端校验逻辑：若检测到$_COOKIE中值异常（如签名不匹配、过期），主动丢弃并重置； - 长期来看，推荐统一使用带前导点的域名（
.mydomain.com）并禁用无点域名写入，从源头规避问题。
通过精准覆盖清除策略，可彻底解决同名 Cookie 冲突问题，确保服务端稳定获取预期值。
