PHP中操作Cookie的核心逻辑其实非常直观：设置、读取和删除。你可以把它想象成在用户浏览器里贴了个小标签，我们用
setcookie()函数来贴这个标签，通过
$_COOKIE这个PHP自带的超全局数组来查看标签内容，而撕掉标签（删除）也只是通过设置一个过去的过期时间来完成。整个过程，说白了，就是服务器和浏览器之间基于HTTP协议的一个小约定。
解决方案
在PHP中，Cookie的操作主要围绕
setcookie()函数和
$_COOKIE超全局变量展开。
1. 设置 Cookie
使用
setcookie()函数来向用户的浏览器发送一个Cookie。这个函数必须在任何实际的HTML输出之前被调用，否则会导致“Headers already sent”错误。
立即学习“PHP免费学习笔记（深入）”；
time() + 3600,
'path' => '/',
'domain' => '', // 通常留空，表示当前域名
'secure' => true, // 仅在HTTPS下发送
'httponly' => true, // 无法通过JS访问
'samesite' => 'Lax' // 缓解CSRF攻击
]);
// 设置一个记住用户名的Cookie，有效期更长，例如7天
setcookie("username", "john_doe", [
'expires' => time() + (86400 * 7), // 7天
'path' => '/',
'secure' => true,
'httponly' => true,
'samesite' => 'Lax'
]);
// 也可以使用传统的参数列表形式，但数组形式更清晰，尤其是在PHP 7.3+
// setcookie("user_id", "12345", time() + 3600, "/", "", true, true);
echo "Cookie已设置。";
?>setcookie()
函数参数详解：
-
name
: Cookie的名称。 -
value
: Cookie的值。 -
expires
: Cookie的过期时间，一个Unix时间戳。如果设置为0
或省略，则Cookie在浏览器关闭时过期（会话Cookie）。 -
path
: Cookie在服务器上的可用路径。/
表示整个域名都可用。 -
domain
: Cookie的有效域名。为空表示当前域名。 -
secure
: 布尔值。如果为true
，Cookie只在HTTPS连接时发送。 -
httponly
: 布尔值。如果为true
，Cookie无法通过JavaScript访问，有助于防止XSS攻击。 -
samesite
: (PHP 7.3+) 字符串。Lax
、Strict
、None
。用于防止CSRF攻击。Lax
是常用且安全的默认值。
2. 读取 Cookie
已设置的Cookie可以通过
$_COOKIE超全局数组来访问。
用户名是: " . htmlspecialchars($username);
} else {
echo "
未找到用户名 Cookie。";
}
?>这里需要注意一点，
$_COOKIE数组只包含浏览器在当前请求中发送过来的Cookie。如果你在一个请求中设置了Cookie，然后立即尝试读取它，在同一个请求中是读不到的，它会在下一个请求中才可用。这是一个常见的初学者误区，我当初也在这里卡过一阵。
3. 删除 Cookie
删除Cookie的本质是设置一个已经过去的过期时间。这样浏览器会立即将其视为无效并删除。
time() - 3600, // 设置为过去的时间
'path' => '/',
'domain' => '',
'secure' => true,
'httponly' => true,
'samesite' => 'Lax'
]);
// 删除名为 'username' 的Cookie
setcookie("username", "", [
'expires' => time() - 3600, // 设置为过去的时间
'path' => '/',
'secure' => true,
'httponly' => true,
'samesite' => 'Lax'
]);
echo "Cookie已尝试删除。";
?>再次强调，删除Cookie时，
name、
path和
domain参数必须和设置时完全一致。如果路径或域名不匹配，浏览器会认为你在设置一个新的、无效的Cookie，而不是删除已有的。
PHP Cookie安全性如何保障？
谈到Cookie，安全性绝对是绕不过去的话题。毕竟，这些小数据片在用户浏览器里晃悠，很容易成为攻击者的目标。我个人在处理用户认证时，对Cookie的安全性总是抱着十二分的警惕。
首先，httponly
属性是防止跨站脚本（XSS）攻击的利器。当一个Cookie被标记为
httponly时，JavaScript代码就无法通过
document.cookie等方式访问它。这意味着即使你的网站不幸被注入了恶意的JS代码，攻击者也无法轻易窃取用户的会话Cookie，从而降低了会话劫持的风险。我通常会把所有存储会话ID或认证令牌的Cookie都设置为
httponly。
其次，secure
属性确保Cookie只在HTTPS连接下发送。这对于保护Cookie在传输过程中的机密性至关重要。如果你的网站支持HTTPS，那么所有重要的Cookie都应该设置为
secure。想想看，如果用户在一个公共Wi-Fi下使用你的网站，而你的Cookie没有
secure，那么他们的会话ID就可能被嗅探到，这简直是灾难。
再者，samesite
属性是近年来对抗跨站请求伪造（CSRF）攻击的有效手段。它告诉浏览器，这个Cookie是否可以随跨站请求一起发送。
-
Strict
: 最严格，只有当请求是同站发起的，或者用户直接导航到目标网站时，Cookie才会被发送。这几乎完全阻止了CSRF，但可能会影响一些正常的跨站链接。 -
Lax
: 这是一个折衷方案，也是目前很多浏览器的默认行为。它允许顶级导航（比如用户点击一个链接）和GET请求发送Cookie，但POST请求或iframe等嵌入式请求则不会发送。对于大多数用户体验来说，Lax
通常是个不错的选择。 -
None
: 允许所有跨站请求发送Cookie，但必须同时设置secure
属性。这主要用于需要跨站共享Cookie的场景，比如嵌入式内容或第三方认证，但安全风险也最高。 我个人倾向于优先使用Lax
，如果业务确实需要跨站，再慎重考虑None
并确保其他安全措施到位。
最后，不要在Cookie中直接存储敏感信息。密码、信用卡号、个人身份信息等，这些绝不能直接放在Cookie里。Cookie很容易被用户查看和修改，甚至被第三方工具拦截。正确的做法是，在Cookie中存储一个不敏感的、随机生成的会话ID或令牌，然后将真正的敏感数据存储在服务器端的Session中，通过这个ID进行关联。这样即使Cookie被窃取，攻击者也只能拿到一个ID，而无法直接获取到用户的敏感数据。
PHP Cookie与Session有何区别，何时选用？
这是一个老生常谈的问题，但其重要性不言而喻。Cookie和Session都是用于维持Web应用状态的机制，但它们的实现原理、存储位置和适用场景大相径庭。理解它们之间的差异，对于构建健壮安全的Web应用至关重要。
Cookie，就像我们前面说的，是服务器发送给浏览器的一小段文本信息，存储在客户端（用户的浏览器）上。它的特点是：
- 客户端存储：数据在用户本地。
- 大小限制：通常单个Cookie不超过4KB，且一个域名下的Cookie总数也有限制。
- 安全性较低：用户可以查看、修改，也可能被XSS攻击窃取。
- 无状态：HTTP协议本身是无状态的，Cookie是用来弥补这一缺陷的。
Session，则是一个服务器端的机制。当用户访问网站时，服务器会为这个用户创建一个唯一的Session，并将Session ID（通常是一个随机字符串）通过Cookie发送给浏览器。浏览器在后续请求中带上这个Session ID，服务器就能识别用户并加载对应的Session数据。它的特点是：
- 服务器端存储：实际数据存储在服务器上（文件、数据库、缓存等），浏览器只存储一个Session ID。
- 无大小限制：理论上只受服务器资源限制。
- 安全性较高：敏感数据不直接暴露给客户端。
- 有状态：通过Session ID，服务器可以追踪用户的整个会话过程。
何时选用？
我的经验是，选择哪种机制，主要取决于数据的敏感性、大小以及你希望数据存储在哪里。
选用Cookie的场景：
- 记住用户偏好：比如网站的主题颜色、语言设置、字体大小等。这些数据不敏感，且用户可能希望在下次访问时依然保持。
- “记住我”功能：通过存储一个长期有效的、加密过的令牌（而非用户密码），实现用户在一段时间内免登录。当然，这需要配合更复杂的安全策略。
- 购物车ID：在用户未登录时，存储一个临时的购物车ID，方便用户下次访问时继续购物。但具体的商品列表数据，通常还是在服务器端通过这个ID关联。
- 用户跟踪/分析：记录用户的访问路径、点击行为等，用于数据分析，但需注意隐私合规。
选用Session的场景：
- 用户登录状态：这是Session最典型的应用。一旦用户登录，服务器会创建Session并存储用户ID、权限等敏感信息，通过Session ID来维持登录状态。
- 存储敏感数据：任何不希望暴露给客户端的数据，如用户的权限列表、支付信息、临时生成的验证码等。
- 大型数据集合：如果需要存储的数据量较大，超出Cookie的限制，Session是更好的选择。
- 防止CSRF攻击：在Session中存储一个CSRF令牌，并与表单中的令牌进行比对，可以有效防止CSRF。
简单来说，Cookie是你的“小纸条”，适合记录一些不那么重要、可以公开或者方便用户修改的信息；而Session则是你的“保险柜”，用来存放那些需要严格保密、不希望被篡改的关键信息。两者经常配合使用，Session ID通过Cookie传递，共同构建了Web应用的状态管理体系。
PHP Cookie设置时有哪些常见陷阱和最佳实践？
即便Cookie看似简单，但在实际开发中，我见过不少开发者在这里踩坑。有些问题看似细微，却可能导致功能异常或安全漏洞。
常见陷阱：
-
setcookie()
之前有输出：这是最经典的错误。PHP的setcookie()
函数需要修改HTTP响应头。如果在此之前，你的脚本已经通过echo
、HTML代码、甚至是文件开头的BOM（Byte Order Mark）输出了任何内容，PHP就会抛出“Headers already sent”的错误。调试这种问题有时会让人抓狂，因为输出可能来自意想不到的地方。正确做法是，确保所有
setcookie()
调用都在任何输出之前。 -
过期时间设置不当：
- 太短：如果一个“记住我”的Cookie过期时间太短，用户会频繁被登出，体验极差。
- 太长：如果会话Cookie（非“记住我”）的过期时间过长，或者不设置（变成会话Cookie），在某些场景下可能增加安全风险，比如用户在公共电脑上忘记关闭浏览器。
-
未考虑时区：
time()
函数返回的是UTC时间戳，但用户可能位于不同时区。不过，Cookie的过期时间通常都是基于UTC来计算的，所以这通常不是大问题，但了解其原理很重要。
路径和域名不匹配：删除或更新Cookie时，
path
和domain
参数必须与设置时完全一致。如果设置了一个路径为/blog
的Cookie，而你尝试用路径/
去删除它，是不会成功的。这就像你给文件起了个名字，却用另一个名字去删除它一样。未设置
httponly
和secure
：这是安全上的疏忽。不设置httponly
可能导致XSS攻击窃取Cookie，不设置secure
则可能在HTTP连接下泄露Cookie。直接存储敏感数据：前面已经强调过，这是大忌。Cookie不是保险箱，不要放密码、支付信息等。
最佳实践：
始终在脚本顶部设置Cookie：为了避免“Headers already sent”错误，一个好的习惯是将所有
setcookie()
调用放在PHP脚本的最顶部，在任何HTML或echo
语句之前。或者，利用输出缓冲（ob_start()
）来捕获输出，并在发送HTTP头之前处理。-
合理设置过期时间：
- 对于会话管理，如果不是“记住我”功能，通常设置为浏览器关闭时过期，或者一个较短的固定时间（如30分钟到1小时）。
- 对于“记住我”功能，可以设置为几天到几个月，但要确保Cookie值是加密的、一次性的或带有刷新机制的令牌，而不是用户凭证。
-
使用数组形式的
setcookie()
参数（PHP 7.3+）：这让代码更清晰，可读性更好，也方便管理各种属性。setcookie("name", "value", ['expires' => time() + 3600, 'path' => '/', 'secure' => true, 'httponly' => true, 'samesite' => 'Lax']); 为所有重要Cookie设置
httponly
和secure
：这应该是默认的安全配置。如果你的网站是HTTPS，secure
更是必须的。利用
samesite
属性：根据你的应用场景，选择Lax
或Strict
来增强CSRF防护。如果确实需要跨站共享Cookie（例如OAuth），再考虑None
并确保有其他CSRF防护措施。只存储非敏感标识符：Cookie中只存放Session ID、加密的令牌或用户偏好等非敏感数据。真正敏感的用户信息应该存储在服务器端的Session中。
封装Cookie操作：如果你在构建一个大型应用，考虑创建一个专门的Cookie管理类或函数。这样可以集中处理Cookie的设置、读取和删除逻辑，确保所有Cookie都遵循统一的安全和最佳实践，例如自动添加
httponly
、secure
和samesite
属性，避免每次手动编写。这不仅提高了代码复用性，也降低了出错的概率。
