操作session必须先调用session_start()且不能有任何输出；2. 设置session通过$_session数组赋值，读取前需检查是否存在；3. 销毁单个session用unset()，销毁全部需调用session_destroy()并清空数组；4. 设置cookie使用setcookie()函数，必须在输出前调用并设置正确参数；5. 读取cookie通过$_cookie超全局变量；6. 删除cookie需用setcookie()将过期时间设为过去时间；7. session数据存服务器更安全，适合敏感信息；8. cookie数据存客户端有大小和安全限制，适合非敏感小数据；9. 登录后应调用session_regenerate_id(true)防止会话固定攻击；10. session id cookie应设置secure和httponly标志增强安全性；11. 避免cookie存储敏感信息以防泄露；12. 设置samesite属性可防范csrf攻击；13. “headers already sent”错误常因输出前调用session_start()或setcookie()导致；14. cookie的path和domain设置不当会导致无法正常发送；15. 检查session.save_path权限和浏览器是否禁用cookie可解决常见失效问题；16. 使用var_dump和浏览器开发者工具可有效调试session和cookie状态。因此，正确使用session和cookie需遵循调用顺序、注意存储位置与安全配置，并通过工具排查常见问题，才能在无状态http协议上可靠维持用户状态。
PHP中操作Session和Cookie，本质上是为了在无状态的HTTP协议之上，为我们的用户维护一种“记忆”或“状态”。简单来说，Session是服务器端存储用户数据的一种方式，通过一个唯一的Session ID（通常存在Cookie里）来识别用户；而Cookie则是直接在用户浏览器端存储少量数据。两者都是为了让网站能记住你，比如你是否登录、购物车里有什么，或者你上次访问时偏好的主题色。
解决方案
要操作Session和Cookie，我们主要围绕它们的设置、读取和销毁来展开。
操作Session
立即学习“PHP免费学习笔记（深入）”；
在使用Session之前，你必须调用
session_start()
函数。这是关键一步，而且必须在任何输出到浏览器之前执行，否则你会遇到恼人的“Headers already sent”错误。一旦
session_start()
被调用，PHP就会检查是否有Session ID被发送过来（通常在Cookie里），如果没有，它会生成一个新的Session ID。
设置Session变量非常直观，就像操作一个普通的关联数组：
<?php session_start(); // 确保在任何HTML输出之前调用 // 设置一个Session变量 $_SESSION['username'] = '张三'; $_SESSION['user_id'] = 123; $_SESSION['cart'] = ['item1' => 2, 'item2' => 1]; echo "用户名: " . $_SESSION['username']; ?>
读取Session变量也同样简单：
<?php
session_start();
if (isset($_SESSION['username'])) {
echo "欢迎回来，" . $_SESSION['username'];
} else {
echo "请登录。";
}
?>
销毁单个Session变量，你可以使用
unset()
：
<?php
session_start();
if (isset($_SESSION['cart'])) {
unset($_SESSION['cart']); // 移除购物车数据
echo "购物车已清空。";
}
?>
要彻底销毁所有Session数据，并结束当前会话，你需要调用
session_destroy()
。但请注意，
session_destroy()
并不会立即清除
$_SESSION
数组中的数据，你可能还需要手动清空它：
<?php session_start(); // 清空所有Session变量 $_SESSION = array(); // 销毁Session文件或数据 session_destroy(); echo "您已成功登出。"; ?>
操作Cookie
Cookie的设置主要通过
setcookie()
函数完成。这个函数也必须在任何输出到浏览器之前调用。它接受多个参数：
-
name
登录后复制: Cookie的名称。
-
value
登录后复制: Cookie的值。
-
expire
登录后复制登录后复制: Cookie的过期时间（Unix时间戳）。如果设置为0或省略，则Cookie在浏览器关闭时失效（会话Cookie）。
-
path
登录后复制登录后复制登录后复制登录后复制: Cookie在服务器上的可用路径。默认是当前路径。
-
domain
登录后复制登录后复制登录后复制登录后复制: Cookie的可用域。
-
secure
登录后复制登录后复制登录后复制: 如果为true，Cookie只通过HTTPS发送。
-
httponly
登录后复制登录后复制登录后复制登录后复制登录后复制: 如果为true，Cookie只能通过HTTP协议访问，JavaScript无法访问，这有助于防止XSS攻击。
设置一个Cookie的例子：
<?php
// 设置一个名为'user_pref'的Cookie，值为'dark_mode'，30天后过期
setcookie('user_pref', 'dark_mode', time() + (86400 * 30), '/'); // 86400秒 = 1天
// 设置一个会话Cookie，浏览器关闭即失效
setcookie('last_visit', date('Y-m-d H:i:s'), 0, '/');
echo "Cookie已设置。";
?>
读取Cookie的值，通过
$_COOKIE
超全局变量：
<?php
if (isset($_COOKIE['user_pref'])) {
echo "您的偏好设置是: " . $_COOKIE['user_pref'];
} else {
echo "没有找到您的偏好设置Cookie。";
}
?>
删除一个Cookie，你需要使用
setcookie()
函数，将过期时间设置为一个过去的时间：
<?php
// 假设要删除名为'user_pref'的Cookie
setcookie('user_pref', '', time() - 3600, '/'); // 将过期时间设为一小时前
echo "Cookie已删除。";
?>
Session与Cookie，我到底该选哪个？它们有什么本质区别？
这几乎是我每次做项目都会思考的问题，到底什么时候用Session，什么时候用Cookie？它们的本质区别在于数据存储的位置和安全性。
Session，它把数据存在服务器上。你想想看，我把你的登录状态、购物车内容这些敏感或重要的数据放在我这边，只给你一个“凭证”（Session ID），你每次来访问，带着这个凭证，我就知道你是谁，你的数据都在哪儿。这样一来，数据本身是安全的，不会被你的浏览器或者其他恶意脚本直接读取到。它的容量理论上只受限于服务器的存储资源，可以存很多东西。但是，这也意味着服务器需要承担存储和管理的开销。
Cookie则完全不同，它把数据直接存在你的浏览器里。就像我给你一张小纸条，上面写着你的偏好设置，比如“你喜欢深色模式”。你下次访问我的网站时，浏览器会自动把这张小纸条带给我。它的好处是减轻了服务器的负担，而且对于一些非敏感、少量的数据（比如用户偏好、广告追踪ID）非常方便。但缺点也显而易见：数据直接暴露在客户端，安全性较低，如果存了敏感信息，很容易被篡改或窃取。而且，Cookie有大小限制，通常一个Cookie不能超过4KB，一个域名下的Cookie总数也有限制。
所以，我的选择通常是：敏感且重要的数据，比如用户登录状态、权限信息、购物车内容等，我会毫不犹豫地选择Session。 而非敏感、少量且需要长期保存的数据，比如用户界面偏好、上次访问时间、不重要的用户ID等，Cookie是更好的选择。 很多时候，Session的ID本身就是通过Cookie来传递的，两者是协同工作的关系，而不是非此即彼。
PHP会话管理中常见的安全陷阱有哪些，我该如何规避？
会话管理听起来简单，但安全问题却不少，踩过坑的人都知道，一不小心就可能导致用户数据泄露或者账户被盗用。我个人最关注的几个点：
-
会话劫持（Session Hijacking）和会话固定（Session Fixation）：
- 会话劫持：攻击者通过某种方式获取了你的Session ID，然后用这个ID冒充你登录。这就像他偷走了你的门禁卡。
- 会话固定：攻击者在用户登录前，就给他一个预设的Session ID，然后诱导用户用这个ID登录。一旦用户登录，攻击者就用这个ID登录，获取用户的权限。这就像攻击者提前给你一把他能复制的钥匙。
-
规避：
-
登录后重新生成Session ID：这是最有效的防御手段之一。用户登录成功后，立即调用
session_regenerate_id(true)
登录后复制。这会生成一个新的Session ID，并废弃旧的ID，让攻击者手中的旧ID失效。
- 使用HTTPS：确保整个网站都使用HTTPS。这样Session ID在传输过程中会被加密，大大降低被窃听的风险。
-
设置Cookie的
secure
登录后复制登录后复制登录后复制和
httponly
登录后复制登录后复制登录后复制登录后复制登录后复制标志
：setcookie()
登录后复制登录后复制登录后复制登录后复制登录后复制函数中的
secure
登录后复制登录后复制登录后复制参数设为
true
登录后复制登录后复制，确保Cookie只在HTTPS连接下发送。
httponly
登录后复制登录后复制登录后复制登录后复制登录后复制设为
true
登录后复制登录后复制，可以防止JavaScript通过
document.cookie
登录后复制登录后复制访问Session ID所在的Cookie，从而降低XSS攻击窃取Session ID的风险。
-
登录后重新生成Session ID：这是最有效的防御手段之一。用户登录成功后，立即调用
-
跨站脚本攻击（XSS）对Cookie的威胁：
- 如果你的网站存在XSS漏洞，攻击者可以注入恶意JavaScript代码，然后通过
document.cookie
登录后复制登录后复制读取用户的Cookie，包括Session ID。
-
规避：
-
httponly
登录后复制登录后复制登录后复制登录后复制登录后复制标志
：正如上面提到的，为Session ID的Cookie设置httponly
登录后复制登录后复制登录后复制登录后复制登录后复制标志，这是防止XSS窃取Session ID最直接有效的方法。
- 严格的用户输入过滤和输出转义：从根本上杜绝XSS漏洞，这是治本之策。
-
- 如果你的网站存在XSS漏洞，攻击者可以注入恶意JavaScript代码，然后通过
-
Cookie敏感信息泄露：
- 有些人为了方便，直接把用户名、用户ID甚至一些敏感数据存在Cookie里。这简直是把密码写在纸条上贴在显示器旁边。
-
规避：
- 绝不在Cookie中存储敏感信息：任何需要保密或验证的数据都应该存储在Session中，或通过其他安全的加密方式处理。Cookie只适合存储非敏感、可公开或可重建的数据。
-
Cookie的
SameSite
登录后复制登录后复制属性：
- 这是一个相对新的Cookie属性，用来防止CSRF（跨站请求伪造）攻击。它可以限制Cookie在跨站请求时是否发送。
-
规避：
- 在
setcookie()
登录后复制登录后复制登录后复制登录后复制登录后复制或PHP配置中设置
SameSite
登录后复制登录后复制属性，比如
Lax
登录后复制或
Strict
登录后复制。例如：
setcookie('name', 'value', ['samesite' => 'Lax']);登录后复制
- 在
这些安全措施，有些是配置上的小改动，有些是开发习惯的转变，但它们对于构建一个健壮、安全的Web应用至关重要。
为什么我的Session或Cookie不生效？排查思路和常见误区。
这问题我被问过无数次，自己也遇到过。很多时候，不是代码逻辑错了，而是环境或者一些小细节没注意到。
-
“Headers already sent”错误：
- 这是最经典的错误了，
session_start()
登录后复制登录后复制登录后复制和
setcookie()
登录后复制登录后复制登录后复制登录后复制登录后复制都要求在任何HTTP头部信息发送之前调用。这意味着，在它们之前不能有任何HTML输出（包括空格、空行、BOM头）。
-
排查：检查你的PHP文件，确保
<?php
登录后复制标签之前没有空行或空格。有时候是引入的文件里有输出。使用PHP的
ob_start()
登录后复制和
ob_end_flush()
登录后复制可以缓冲输出，但这不是解决根本问题的办法，最好还是遵守规则。
- 这是最经典的错误了，
-
Cookie的路径（
path
登录后复制登录后复制登录后复制登录后复制）和域（
domain
登录后复制登录后复制登录后复制登录后复制）问题：
- 如果你设置Cookie时指定了
path
登录后复制登录后复制登录后复制登录后复制或
domain
登录后复制登录后复制登录后复制登录后复制，而访问页面时路径或域不匹配，Cookie就不会被发送到服务器。
-
排查：确保
path
登录后复制登录后复制登录后复制登录后复制参数设置为
/
登录后复制（表示整个域名下都可用），或者与你希望Cookie生效的目录匹配。
domain
登录后复制登录后复制登录后复制登录后复制参数通常可以省略，让它默认为当前域名。如果你在
sub.example.com
登录后复制设置了Cookie，而你访问
www.example.com
登录后复制，那Cookie是不会发送的。
- 如果你设置Cookie时指定了
-
Cookie过期时间设置错误：
- 如果你设置的过期时间是过去的时间，Cookie会立即失效。或者时间设置太短，导致很快就过期。
-
排查：确保
expire
登录后复制登录后复制参数是
time() + 秒数
登录后复制，例如
time() + 3600
登录后复制表示一小时后过期。
-
浏览器禁用Cookie：
- 有些用户出于隐私考虑，会禁用浏览器Cookie。在这种情况下，你的Cookie操作自然不会生效。
- 排查：作为开发者，你可以在浏览器设置中检查。但对于用户来说，你可能需要提供一个友好的提示。
-
Session文件存储权限或路径问题：
- Session数据通常存储在服务器的临时目录中。如果PHP没有写入该目录的权限，或者
session.save_path
登录后复制登录后复制配置不正确，Session就无法正常工作。
-
排查：检查
php.ini
登录后复制中的
session.save_path
登录后复制登录后复制配置，并确保该目录存在且PHP进程有写入权限。在Linux上，这通常是
/tmp
登录后复制目录，需要确保权限正确。
- Session数据通常存储在服务器的临时目录中。如果PHP没有写入该目录的权限，或者
-
网络或缓存问题：
- 虽然不常见，但CDN缓存、反向代理或浏览器自身的缓存，有时会干扰到Session或Cookie的正确传递。
- 排查：清除浏览器缓存，或者在开发时禁用缓存。
-
调试技巧：
-
查看
$_SESSION
登录后复制登录后复制和
：使用$_COOKIE
登录后复制登录后复制var_dump($_SESSION);
登录后复制和
var_dump($_COOKIE);
登录后复制来直接查看当前Session和Cookie中的内容，这是最直接的调试方法。
- 浏览器开发者工具：在浏览器的开发者工具（F12）中，查看“Application”（或“存储”、“网络”）选项卡，可以清晰地看到当前页面设置了哪些Cookie，它们的名称、值、过期时间、路径和域等信息。在“Network”选项卡中，你也可以看到每次请求发送和接收的HTTP头部，包括Cookie和Session ID。
-
查看
这些排查思路，很多时候就是一点点地“排除法”，从最常见的错误开始检查，通常就能找到问题所在。
以上就是PHP如何操作Session和Cookie PHP会话管理的实用指南的详细内容，更多请关注php中文网其它相关文章！