必须在任何输出前调用 session_start()，否则因响应头已发送而触发警告；它负责读取id、加载数据、准备存储，且仅在需读写 $_session 时调用才合理。
必须在任何输出之前调用 session_start()
PHP 会话依赖于 HTTP 响应头（如 Set-Cookie）来传递 PHPSESSID，一旦有空白、echo、HTML 或 BOM 字符被输出，headers 就已发送，此时再调用 session_start() 会触发「Cannot send session cache limiter」警告，会话无法启动。
常见踩坑点：
- 文件开头存在 UTF-8 BOM（尤其 Windows 编辑器保存时默认带 BOM）
<?php前有空格或换行- 包含的配置文件末尾有多余空行或
?>后跟空格 - 错误开启
output_buffering却误以为能“兜底”
稳妥做法：所有会话操作前加 if (session_status() === PHP_SESSION_NONE) { session_start(); }，避免重复启动报错。
session_start() 的实际作用不只是“开个会话”
它真正做三件事：读取客户端传来的 PHPSESSID（从 Cookie 或 URL），加载对应会话数据到 $_SESSION 数组，同时为后续写入准备会话存储机制（如文件、Redis）。
立即学习“PHP免费学习笔记（深入）”；
关键细节：
- 若客户端没带有效
PHPSESSID，PHP 自动生成新 ID 并通过响应头返回（首次访问必触发 Set-Cookie） - 默认使用
files存储，会话文件路径由session.save_path决定，需确保 Web 进程有写权限 - 不调用
session_start()就直接读写$_SESSION，数据不会持久化，也不会关联到任何会话 ID - 启用
session.use_cookies=0时，ID 只能靠 URL 传递（?PHPSESSID=xxx），极不安全，不建议
何时该调用、何时不该调用 session_start()
不是每个脚本都需要会话。盲目在所有入口都加 session_start() 会导致不必要的文件锁（尤其用 files 存储时）、性能下降，还可能阻塞并发请求。
合理策略：
- 仅在确实需要读/写
$_SESSION的脚本中调用（如登录页、用户中心、购物车接口） - 静态资源（CSS/JS/图片）、纯 API（无状态）、CLI 脚本通常不需要会话
- 如果只是读取会话（如判断是否登录），仍需
session_start()—— 因为数据还没加载进$_SESSION - 想提前关闭会话释放锁？用
session_write_close()，之后不能再写$_SESSION，但可继续读
示例：一个只验证登录态的中间件片段
if (session_status() === PHP_SESSION_NONE) {
session_start();
}
if (!isset($_SESSION['user_id'])) {
http_response_code(401);
exit('Unauthorized');
}
会话配置影响 session_start() 行为
很多问题其实出在 ini 配置，而非函数本身调用方式。几个关键项：
-
session.cookie_httponly=1：防止 JS 访问 Cookie，增强 XSS 防御 -
session.cookie_secure=1：强制 Cookie 只走 HTTPS（生产环境必须开） -
session.cookie_samesite=Lax：缓解 CSRF，默认Lax已较安全，Strict兼容性差 -
session.gc_maxlifetime：决定会话过期时间（单位秒），注意和ini_set('session.gc_maxlifetime', 3600)配合使用
修改后需重启 PHP-FPM 或 Web 服务器才生效（某些 SAPI 下动态设置无效）。调试时可用 var_dump(ini_get('session.cookie_httponly')); 确认当前值。
会话不是万能钥匙，ID 泄露、未及时销毁、跨域共享不当，都会让整个机制失效。别只盯着 session_start() 是否执行成功，更要盯住 Cookie 属性、存储权限、GC 时机这些容易被忽略的环节。
