php如何读取和设置cookie？php中cookie的读取与设置操作

下次还敢

发布时间：2025-09-23 15:42:01

327人浏览过

来源于php中文网

原创

答案：PHP中通过setcookie()设置Cookie、$_COOKIE读取Cookie，需注意发送时机、路径域名匹配及安全标志。

php如何读取和设置cookie？php中cookie的读取与设置操作

PHP中读取Cookie主要通过$_COOKIE这个超全局数组，它包含了所有由客户端浏览器发送过来的Cookie数据。而设置Cookie则依赖于setcookie()函数，这个函数允许你向浏览器发送一个HTTP响应头，指示浏览器存储特定的键值对，并可设置其有效期、作用域等。理解这两者是PHP Web开发中处理用户会话和偏好设置的基础。

解决方案

在PHP中操作Cookie，核心就是setcookie()函数和$_COOKIE超全局数组。

设置Cookie：setcookie()函数是用来向用户的浏览器发送一个Cookie。它必须在任何实际的输出（如HTML、空格、echo语句）发送到浏览器之前调用，否则会导致“Headers already sent”错误。

基本语法： setcookie(name, value, expire, path, domain, secure, httponly);

name (必需): Cookie的名称。
value (可选): Cookie的值。
expire (可选): Cookie的过期时间。这是一个Unix时间戳。如果省略或设置为0，Cookie将在浏览器关闭时过期。例如，time() + (86400 * 30)表示30天后过期。
path (可选): Cookie在服务器上的可用路径。默认是当前目录。/表示整个域名下都可用。
domain (可选): Cookie的可用域名。例如，example.com使其在example.com及其所有子域名下可用。
secure (可选): 如果设置为true，Cookie只会在HTTPS连接时发送。
httponly (可选): 如果设置为true，Cookie将无法通过JavaScript访问。这有助于防止跨站脚本（XSS）攻击。

示例：

立即学习“PHP免费学习笔记（深入）”；

读取Cookie： 一旦浏览器接收并存储了Cookie，它会在后续的请求中将其发送回服务器。PHP会将这些Cookie数据填充到$_COOKIE超全局数组中。

示例：

立即学习“PHP免费学习笔记（深入）”；

请注意，htmlspecialchars()在这里的使用是为了防止XSS攻击，即使是读取Cookie的值，也应该考虑到输出时的安全问题。

删除Cookie： 要删除一个Cookie，你只需要用相同的名称再次调用setcookie()函数，并将其过期时间设置为过去的一个时间点。

示例：

立即学习“PHP免费学习笔记（深入）”；

这里，value参数可以为空字符串，关键是expire设置为过去。path和domain参数必须与设置时完全一致，否则浏览器可能无法正确识别并删除对应的Cookie。

PHP Cookie的过期时间与作用域如何精确控制？

对于Cookie的生命周期和可见范围，expire、path和domain这三个参数是核心。精确控制它们，能让你的应用更灵活，也更安全。

过期时间 (expire)： 这个参数决定了Cookie能“活”多久。它不是一个持续时间，而是一个具体的Unix时间戳，表示Cookie何时失效。

会话Cookie： 如果你省略expire参数，或者将其设置为0，那么这个Cookie就成了“会话Cookie”。它会存储在内存中，当用户关闭浏览器时，这个Cookie就会被删除。这对于存储一些临时性的、不希望持久化的信息非常有用，比如用户当前的购物车内容（未登录状态）。
持久化Cookie： 设置一个未来的时间戳，例如time() + (60 * 60 * 24 * 30)表示30天后过期。这种Cookie会被写入用户的硬盘，即使浏览器关闭，只要在过期时间内再次访问，Cookie依然存在。适用于“记住我”功能或用户偏好设置。
删除Cookie： 将expire设置为一个过去的时间戳，如time() - 3600。浏览器会立即删除这个Cookie。

路径 (path)：path参数定义了Cookie在服务器上哪个路径下是可见的。

/ (根路径)： 这是最常见的设置，表示Cookie在整个网站的任何页面都可见。例如，setcookie("user_pref", "dark_mode", time() + ..., "/");。
/admin/ (特定目录)： 如果你只想让某个Cookie在/admin/目录及其子目录下的页面中可见，可以设置setcookie("admin_token", "...", time() + ..., "/admin/");。这样，在/blog/页面就无法访问到这个admin_token。这有助于限制Cookie的可见范围，提升安全性。
默认行为： 如果不指定path，默认是设置Cookie的当前脚本所在的目录。例如，如果脚本在/app/users/下，那么Cookie的默认路径就是/app/users/。

域名 (domain)：domain参数决定了Cookie对哪个域名及其子域名是可见的。

当前域名： 如果省略domain参数，Cookie将只对设置它的当前域名可见，不包括子域名。
主域名及其子域名： 如果你设置domain为.yourdomain.com（注意前面的点），那么Cookie将对yourdomain.com以及所有子域名（如www.yourdomain.com、blog.yourdomain.com）都可见。这在主域名和子域名之间需要共享Cookie（例如单点登录）时非常有用。
特定子域名： 设置domain为blog.yourdomain.com，那么Cookie将只对blog.yourdomain.com可见，而不对www.yourdomain.com或yourdomain.com可见。
安全限制： 你不能设置domain为与当前域名不相关的其他域名，这是出于安全考虑。例如，在example.com下不能设置domain为google.com的Cookie。

处理PHP Cookie时常见的安全隐患与最佳实践是什么？

Cookie虽然方便，但如果使用不当，可能成为安全漏洞的突破口。了解这些隐患并采取最佳实践至关重要。

1. 跨站脚本攻击 (XSS) 与 HttpOnly 标志：

隐患： 如果你的网站存在XSS漏洞，攻击者可以注入恶意JavaScript代码，通过document.cookie访问并窃取用户的Cookie信息，包括会话ID，从而劫持用户会话。
最佳实践： 始终将HttpOnly标志设置为true。
```
setcookie("session_id", $sessionId, time() + 3600, "/", "", false, true); // 最后一个参数为 true
```
当HttpOnly为true时，JavaScript无法通过document.cookie或其他DOM API访问到这个Cookie。这大大降低了XSS攻击的风险，即使页面存在XSS漏洞，攻击者也难以窃取到HttpOnly的Cookie。

2. 中间人攻击 (MITM) 与 Secure 标志：

隐患： 在HTTP（非加密）连接下，Cookie数据在传输过程中是明文的，容易被嗅探或篡改。攻击者可能截获Cookie，进行会话劫持。
最佳实践： 对于所有包含敏感信息（如会话ID）的Cookie，在HTTPS环境下，始终将Secure标志设置为true。
```
setcookie("session_id", $sessionId, time() + 3600, "/", "", true, true); // 倒数第二个参数为 true
```
当Secure为true时，浏览器只会在加密的HTTPS连接下发送这个Cookie。这确保了Cookie在传输过程中的机密性和完整性。

降迹灵AI
用户口碑TOP级的降AIGC率、降重平台

下载

3. 跨站请求伪造 (CSRF) 与 SameSite 属性：

隐患： CSRF攻击利用用户在已登录网站的会话，诱导用户点击恶意链接或图片，在不知情的情况下执行操作（如转账、修改密码）。Cookie默认会随跨站请求发送，为CSRF提供了便利。
最佳实践： 使用SameSite属性。这是一个相对较新的Cookie属性，但现代浏览器支持良好。
- SameSite=Lax (推荐默认)： Cookie只会在同站请求中发送，或者在顶级导航（如点击链接）时发送。对于GET请求，它会发送；对于POST请求，它不会发送。这在很大程度上缓解了CSRF攻击。
- SameSite=Strict： Cookie只在同站请求中发送。即使是点击链接这种顶级导航，如果来源是跨站的，也不会发送Cookie。安全性最高，但可能影响用户体验（例如，从外部链接进入网站需要重新登录）。
- SameSite=None; Secure： 如果你需要Cookie在跨站请求中发送（例如，第三方小部件、OAuth回调），必须同时设置Secure标志。
```
// 设置 SameSite=Lax
setcookie("user_token", $token, [
'expires' => time() + 3600,
'path' => '/',
'domain' => '', // 你的域名
'secure' => true,
'httponly' => true,
'samesite' => 'Lax',
]);
```
  PHP 7.3+ 支持通过数组形式设置setcookie()的选项，更加清晰。

4. 敏感数据存储：

隐患： 直接在Cookie中存储用户的敏感信息（如密码、身份证号、银行卡号）是极其危险的。即使Cookie被加密，客户端也可能被攻破。
最佳实践： 绝不在Cookie中直接存储敏感数据。Cookie通常只用于存储不敏感的用户偏好或一个随机生成的、难以猜测的会话ID/令牌。所有实际的用户数据都应存储在服务器端的会话（$_SESSION）或数据库中，通过会话ID进行关联。

5. Cookie值篡改：

隐患： 攻击者可能会尝试修改Cookie的值，以绕过验证或获取未授权的权限。
最佳实践：
- 对所有从Cookie中读取的值进行严格的服务器端验证和过滤。永远不要信任客户端发送过来的数据。
- 对于一些关键的、非敏感但又希望防止篡改的数据（如“购物车ID”），可以考虑对Cookie值进行数字签名，服务器端验证签名，确保数据未被篡改。

为什么我的PHP `setcookie()` 调用无效或报错？

setcookie() 函数在PHP中非常常用，但它对调用时机和参数有严格要求。遇到无效或报错的情况，通常是以下几个原因：

1. "Headers already sent" 错误 (最常见)

问题描述： setcookie()函数需要发送HTTP头信息给浏览器。根据HTTP协议，头信息必须在任何实际的内容（HTML、空格、换行符、echo输出、BOM头等）发送之前发送。如果你在setcookie()之前有任何输出，PHP就会抛出“Cannot modify header information - headers already sent by...”的警告或错误。
解决方案：
- 确保你的setcookie()调用在PHP脚本的最顶部，在任何HTML标签、echo语句、甚至文件开头的空白字符之前。
- 检查PHP文件是否有BOM（Byte Order Mark）头。某些文本编辑器在保存UTF-8文件时会添加BOM，这会被PHP识别为输出。可以尝试用纯文本编辑器（如Notepad++、VS Code）将文件保存为“UTF-8 无BOM”格式。
- 使用输出缓冲 (ob_start())：在脚本开始处调用ob_start()，它会捕获所有输出，直到脚本结束或调用ob_end_flush()。这样，你就可以在脚本的任何位置调用setcookie()，因为实际的输出会在缓冲区刷新时才发送。
// ... 你的代码，可能包含一些输出 ...

setcookie("my_cookie", "value", time() + 3600, "/");

// ... 更多代码 ...

ob_end_flush(); // 在脚本结束时刷新输出缓冲区 ?>

2. Cookie路径 (path) 或域名 (domain) 设置不正确

问题描述： 如果你设置的path或domain过于严格，或者与你当前访问的页面不匹配，浏览器就不会发送这个Cookie。例如，你在/admin/路径下设置了一个Cookie，但却在/index.php页面尝试读取它，那么它将不可见。
解决方案：
- 确保setcookie()时path和domain参数与你希望Cookie可见的范围一致。通常，为了让Cookie在整个网站可见，path设置为/。
- 在删除Cookie时，path和domain也必须与设置时完全一致，否则浏览器无法找到并删除对应的Cookie。

3. Cookie过期时间 (expire) 设置错误

问题描述： 如果你将expire时间设置成了过去的时间，或者是一个无效的时间戳，Cookie可能会立即过期或根本不被设置。
解决方案：
- expire参数必须是一个Unix时间戳。确保你使用的是time() + seconds的格式来设置未来的时间。
- 删除Cookie时，将expire设置为time() - 3600（一小时前）是一个安全且常用的做法。

4. secure 标志与 HTTP 连接不匹配

问题描述： 如果你将secure参数设置为true，但你的网站当前是通过HTTP（非加密）连接访问的，浏览器出于安全考虑将不会设置这个Cookie。
解决方案：
- 确保你的网站是通过HTTPS访问的，或者在测试阶段，将secure参数设置为false。在生产环境中，对于敏感Cookie，始终建议使用HTTPS并设置secure为true。

5. 浏览器设置或扩展

问题描述： 用户的浏览器可能禁用了Cookie，或者安装了广告拦截、隐私保护等浏览器扩展，这些扩展可能会阻止Cookie的设置或读取。
解决方案：
- 这通常是客户端问题，超出服务器端控制。你可以通过在网站上提示用户检查其浏览器设置来解决。但在开发和测试阶段，这需要你手动检查浏览器设置。

6. Cookie名称冲突或限制