在PHP中，设置Cookie主要依赖
setcookie()
函数，它必须在任何内容输出到浏览器之前被调用。而获取Cookie则通过超全局变量
$_COOKIE
数组实现，这个数组包含了所有由浏览器发送过来的Cookie数据。理解这两个核心机制，是有效管理用户会话和偏好的基础。
解决方案
PHP中对Cookie的设置与读取操作，本质上就是围绕
setcookie()
函数和
$_COOKIE
超全局变量展开。
设置Cookie
要设置一个Cookie，我们使用
setcookie()
函数。这个函数有很多参数，但最常用的是Cookie的名称、值和过期时间。一个关键点是，
setcookie()
函数必须在任何HTML内容、空白字符或
echo
语句输出到浏览器之前被调用。这是因为Cookie信息作为HTTP响应头的一部分发送，一旦响应头发送完毕，就无法再添加新的头信息了。
立即学习“PHP免费学习笔记（深入）”；
time() + (86400 * 30), // 30天后过期 'path' => '/', // 整个站点可用 'domain' => '.example.com', // 适用于example.com及其所有子域 'secure' => true, // 仅通过HTTPS发送 'httponly' => true, // 阻止JavaScript访问 'samesite' => 'Lax' // 默认的跨站请求策略 ]);// 此时，如果后面有任何输出，会抛出"Headers already sent"的警告// echo "Cookie已设置";?>
我个人在使用
setcookie()
时，特别关注
httponly
和
secure
这两个参数。它们是提升Cookie安全性的基石，尤其是在处理用户认证或敏感数据时，几乎是不可或缺的。忘记设置它们，就像给潜在的攻击者留了一扇后门。
获取Cookie
一旦Cookie被设置并由浏览器发送回来，我们就可以通过PHP的
$_COOKIE
超全局数组来访问它。
$_COOKIE
是一个关联数组，其键是Cookie的名称，值是对应的Cookie值。
<?php// 确保在访问前检查Cookie是否存在，避免Undefined index错误if (isset($_COOKIE['username'])) { $username = $_COOKIE['username']; echo "欢迎回来，" . htmlspecialchars($username) . "！
";} else { echo "您还没有设置用户名Cookie。
";}if (isset($_COOKIE['user_pref'])) { $user_pref = $_COOKIE['user_pref']; echo "您的用户偏好是：" . htmlspecialchars($user_pref) . "
";}// 访问我们之前设置的session_idif (isset($_COOKIE['session_id'])) { echo "您的会话ID是：" . htmlspecialchars($_COOKIE['session_id']) . "
";}?>
我发现，很多初学者容易忘记检查
isset($_COOKIE['name'])
，这在Cookie不存在时会导致不必要的错误。养成这种良好的习惯，能让代码健壮很多。
删除Cookie
要删除一个Cookie，我们实际上是设置一个同名Cookie，但将其过期时间设置为过去的一个时间点（例如
time() - 3600
）。重要的是，
path
和
domain
参数必须与原始Cookie设置时完全匹配，否则浏览器会认为这是一个新的Cookie，而不是要删除旧的。
time() - 3600, // 设置为过去的时间 'path' => '/', // 必须与原Cookie的path一致 'domain' => '.example.com', // 必须与原Cookie的domain一致 'secure' => true, // 必须与原Cookie的secure一致 'httponly' => true, // 必须与原Cookie的httponly一致 'samesite' => 'Lax' // 必须与原Cookie的samesite一致 ]);echo "Cookie已尝试删除。
";?>
删除Cookie时，最常见的错误就是
path
和
domain
不匹配。我曾经因为这个问题浪费了不少时间调试，结果发现只是路径设置错了。所以，记住，删除操作必须精确地“定位”到要删除的那个Cookie。
PHP Cookie的生命周期与作用域如何理解？
理解Cookie的生命周期和作用域对于有效管理用户数据至关重要，它直接影响着Cookie何时可用、在哪里可用以及能持续多久。这不仅仅是技术细节，更是设计用户体验和安全策略的基础。
生命周期 (Expires)
Cookie的生命周期由
setcookie()
函数的
expires
参数决定。这个参数接受一个Unix时间戳，表示Cookie何时失效。
会话Cookie（Session Cookie）：当我们不设置
expires
参数，或者将其设置为
0
时，这个Cookie就是一个会话Cookie。这意味着它会在用户关闭浏览器时自动删除。这种Cookie常用于存储临时的会话信息，比如用户登录状态（通常是会话ID），一旦浏览器关闭，会话就结束了。我认为，对于那些不需要长期记住用户的信息，或者对安全性要求较高的临时状态，会话Cookie是首选。持久化Cookie（Persistent Cookie）：如果
expires
参数被设置为未来的某个时间戳，那么Cookie就会在用户的硬盘上存储，直到达到这个过期时间，或者用户手动清除它。例如，
time() + 86400 * 30
会将Cookie设置为30天后过期。这种Cookie常用于“记住我”功能、用户偏好设置或跟踪分析。我个人觉得，虽然方便用户，但持久化Cookie也增加了被窃取的风险，所以存储在其中的信息需要格外谨慎。
过期时间是相对服务器时间的。如果客户端时间不准确，可能会导致Cookie行为异常，但这通常不是我们开发者需要直接处理的问题，浏览器会负责管理。
作用域 (Path & Domain)
Cookie的作用域决定了哪些URL路径和哪些域名可以访问到这个Cookie。这是控制Cookie可见性和安全性的重要机制。
路径 (Path)：
path
参数指定了Cookie在服务器上的哪个路径下是可用的。
path = '/'
(默认值)：Cookie对整个域名下的所有路径都可用。这是最常见的设置，也是我个人最常使用的，因为它最简单，能确保Cookie在整个站点范围内都有效。
path = '/blog/'
：Cookie只在
/blog/
及其子路径下可用（例如
/blog/post1
）。这意味着访问
/about/
页面的请求将不会携带这个Cookie。如果未明确设置
path
，它会默认为设置Cookie的当前脚本所在的目录。这有时会导致意想不到的问题，比如你在
/admin/
下设置的Cookie，在
/
主页就无法访问了。所以我建议，除非有特殊需求，否则最好明确设置为
'/'
。
域 (Domain)：
domain
参数指定了Cookie对哪个域名是可用的。
domain = 'example.com'
：Cookie对
example.com
以及所有子域（如
www.example.com
,
blog.example.com
）都可用。请注意，这里需要以点开头，如
.example.com
，才能包含所有子域。如果只写
example.com
，某些浏览器可能只会将其视为精确匹配，不包括子域。如果未明确设置
domain
，它会默认为设置Cookie的当前域名，且不包含子域。这意味着在
www.example.com
上设置的Cookie，在
blog.example.com
上是不可用的。需要注意的是，你不能为一个与你当前域名无关的域名设置Cookie，这是一种安全限制。例如，在
example.com
上，你不能设置一个
domain='google.com'
的Cookie。
我发现，很多时候开发者会忽略
path
和
domain
的精细化设置，导致Cookie在某些页面无法获取，或者在不应该发送的地方也被发送了。特别是当项目涉及到多个子域或复杂的路径结构时，对这两个参数的理解和正确配置就显得尤为关键。它不仅仅是功能层面的考量，更是安全边界的划分。
在PHP中处理Cookie时，有哪些常见的安全陷阱和最佳实践？
Cookie虽然方便，但由于其客户端存储和自动发送的特性，也带来了不少安全隐患。作为开发者，我们必须清醒地认识这些陷阱，并采取相应的最佳实践来加固防线。我个人觉得，安全问题往往不是代码写得多复杂，而是对基础安全原则的理解和坚持。
常见的安全陷阱
跨站脚本攻击 (XSS)：这是最常见的Cookie安全问题之一。如果你的网站存在XSS漏洞，攻击者可以注入恶意JavaScript代码。陷阱：如果Cookie没有设置
httponly
标志，恶意JavaScript就可以直接访问并窃取用户的会话Cookie，从而劫持用户会话。想象一下，如果一个攻击者拿到了你的登录会话ID，他就能以你的身份登录网站，这非常危险。跨站请求伪造 (CSRF)：攻击者诱骗用户在不知情的情况下，向目标网站发送一个恶意请求。陷阱：如果你的网站没有采取CSRF防护措施（例如Token），并且Cookie是自动随请求发送的，那么用户的浏览器在访问恶意网站时，可能会自动携带你的网站的会话Cookie，从而执行攻击者预设的操作（如修改密码、转账等）。中间人攻击 (MITM)：在用户和服务器之间的通信过程中，攻击者拦截并篡改数据。陷阱：如果Cookie没有设置
secure
标志，并且你的网站通过HTTP（而非HTTPS）传输，那么Cookie在传输过程中是明文的，攻击者可以轻易截获并读取其中的敏感信息。在Cookie中存储敏感数据：有些开发者为了方便，会直接在Cookie中存储用户的用户名、密码（即使是加密的）、个人信息等。陷阱：Cookie是存储在用户客户端的，即使加密，也总有被破解的风险。更何况，一旦Cookie被窃取，攻击者就可能获取到这些信息。会话劫持与会话固定：陷阱：如果会话ID是可预测的，或者在用户登录前就分配了会话ID，攻击者可以尝试固定这个ID，并在用户登录后使用它来劫持会话。
最佳实践
始终使用
httponly
标志：实践：在
setcookie()
函数中，将
httponly
参数设置为
true
。这将阻止客户端JavaScript访问Cookie，从而大大降低XSS攻击窃取会话Cookie的风险。这是我个人认为最重要的一个安全设置，几乎所有会话Cookie都应该启用它。
setcookie('session_id', $value, ['httponly' => true, ...]);
始终使用
secure
标志：实践：当你的网站使用HTTPS时（现代Web开发中这应该是标配），将
secure
参数设置为
true
。这会强制浏览器只在通过HTTPS连接发送Cookie，防止Cookie在不安全的HTTP连接中被截获。
setcookie('session_id', $value, ['secure' => true, ...]);
实施
SameSite
策略：实践：
SameSite
属性可以有效防御CSRF攻击。它有三个值：
Lax
(默认值)：在跨站请求中，只有GET请求且是顶级导航（比如用户点击链接跳转）时才会发送Cookie。对于POST请求或其他非顶级导航，Cookie不会发送。这是大多数情况下的推荐设置，因为它在提供安全性的同时，对用户体验影响最小。
Strict
：只有在同站请求中才会发送Cookie。任何跨站请求（包括用户点击链接跳转）都不会发送Cookie。安全性最高，但可能会影响一些正常的跨站交互（如从第三方网站跳转回你的网站后需要重新登录）。
None
：在所有跨站请求中都会发送Cookie。但必须同时设置
secure
标志，否则浏览器会拒绝设置该Cookie。这通常用于需要跨站发送Cookie的场景，例如第三方嵌入式内容。我通常会从
Lax
开始，根据实际需求再考虑
Strict
或
None
。
setcookie('session_id', $value, ['samesite' => 'Lax', ...]);
Cookie中只存储非敏感数据或标识符：实践：永远不要在Cookie中直接存储用户的密码、信用卡号或任何其他敏感的个人信息。如果必须存储，也只应存储一个安全的、随机生成的会话ID或令牌。这些ID或令牌在服务器端映射到真正的用户数据。这样，即使Cookie被窃取，攻击者也只能拿到一个ID，而不是直接的敏感信息。定期轮换会话ID：实践：在用户登录成功后，重新生成一个新的会话ID，并废弃旧的会话ID。这可以有效防止会话固定攻击。PHP的
session_regenerate_id(true)
函数就是为此设计的。对来自Cookie的数据进行验证和净化：实践：任何来自客户端的数据，包括Cookie，都应该被视为不可信的。在应用程序中使用Cookie中的数据之前，务必进行严格的输入验证、净化和转义，以防止注入攻击（如SQL注入、XSS）。例如，使用
htmlspecialchars()
来输出Cookie值。
我认为，安全是一个持续的过程，没有一劳永逸的解决方案。我们作为开发者，需要时刻保持警惕，并不断学习和应用最新的安全实践。
如何在现代Web开发中更优雅地管理PHP Cookie？
在现代Web开发中，我们不再仅仅停留在
setcookie()
和
$_COOKIE
的基础操作上。框架、库以及对Web标准的更深入理解，为我们提供了更优雅、更安全、更高效的Cookie管理方式。这不仅仅是代码层面的优化，更是对整个应用安全性和用户体验的提升。
框架与库的抽象
几乎所有现代PHP框架，如Laravel、Symfony、Yii等，都提供了对Cookie和会话管理的抽象层。我个人非常推荐使用这些框架提供的功能，而不是直接操作
setcookie()
。
简化API：框架通常会提供更简洁、更易读的API来设置、获取和删除Cookie，例如Laravel的
response()->cookie()
方法。默认安全配置：这些框架的Cookie管理通常会默认启用
httponly
、
secure
和
SameSite
等重要安全标志，省去了我们手动配置的麻烦，也降低了因疏忽而导致安全漏洞的风险。会话管理集成：Cookie与会话管理紧密结合。框架的会话管理功能通常基于Cookie（存储会话ID），但实际会话数据存储在服务器端（文件、数据库、Redis等），这是一种更安全的处理敏感数据的方式。通过框架的会话机制，我们只需操作
$_SESSION
，而无需直接干预会话Cookie的设置。
例如，在Laravel中，设置一个Cookie可能只需：
// 设置一个Cookiereturn response('Hello World')->cookie( 'name', 'value', $minutes = 60, $path = '/', $domain = null, $secure = true, $httpOnly = true, $raw = false, $sameSite = 'Lax');// 获取Cookie$value = request()->cookie('name');
这种方式显然比直接调用
setcookie()
要优雅和安全得多。
HttpOnly与Secure的默认化
我坚信，对于任何涉及用户认证或敏感数据的Web应用，
httponly
和
secure
这两个标志应该成为默认配置。现代框架已经很好地实现了这一点，但即使是原生PHP项目，也应该在全局配置中强制启用它们。
httponly
：防止XSS攻击窃取会话Cookie。
以上就是PHP如何设置和获取Cookie_PHP中Cookie的设置与读取操作详解的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1294306.html
微信扫一扫 
支付宝扫一扫 
