php会话需严格遵循调用顺序与配置：session_start()必须置于任何输出前，否则触发“headers already sent”错误；默认文件存储机制要求主动调用session_write_close()避免锁表；跨请求会话依赖cookie或url重写，且需合理配置安全参数。
PHP会话不是“开个函数就能用”，它依赖服务器配置、请求生命周期和正确的调用顺序；漏掉 session_start() 或在输出后调用，会直接导致“headers already sent”错误。
session_start() 必须放在任何输出之前
这是最常踩的坑：哪怕是一个空格、BOM头、echo、HTML标签，都会让 PHP 无法发送 session cookie。Apache/Nginx 日志里看不到明显报错，但浏览器里 $_SESSION 始终为空，或反复新建会话 ID。
- 确保 PHP 文件开头没有空行、UTF-8 BOM（用编辑器“无 BOM UTF-8”保存）
- 不要在
session_start()前有任何print、echo、var_dump()，包括被包含的文件 - 如果用了 Composer 自动加载或框架路由，检查是否有前置日志/调试输出
- 临时调试可用
headers_sent($file, $line)定位哪行触发了输出
$_SESSION 是超级全局数组，但不是实时写入磁盘的
PHP 默认把 session 数据存在文件（session.save_handler = files），写入时机由 session_write_close() 或脚本结束触发。这意味着：并发请求可能读到旧值，长时间运行的脚本可能锁住 session 文件。
- 修改完关键数据后，主动调用
session_write_close()解锁，尤其在执行耗时操作（如 cURL、数据库大查询）前 - 避免在循环中反复赋值
$_SESSION['key'] = $val，先合并再写一次 - 不要用
unset($_SESSION)清空全部——它只销毁数组引用；正确做法是$_SESSION = []或逐个unset($_SESSION['key']) - 注意
session.gc_maxlifetime配置，它决定服务端 session 文件存活时间，和客户端 cookie 过期时间无关
跨请求保持会话要处理好 Cookie 和 URL 重写
默认情况下，PHP 通过 Set-Cookie 响应头传递 PHPSESSID；若客户端禁用 Cookie，且没开启 session.use_trans_sid，会话就断了。
- 生产环境不建议开启
session.use_trans_sid（会把 session_id 拼进 URL，有泄露和 SEO 风险） - 确保
session.cookie_secure = 1（HTTPS 下才发 Cookie）和session.cookie_httponly = 1（JS 无法读取）已启用 - 使用
session_set_cookie_params()可动态设置 domain/path，比如子域名共享会话：session_set_cookie_params(0, '/', '.example.com') - 如果用 Nginx，确认没用
fastcgi_ignore_headers "Set-Cookie"这类配置屏蔽了 Cookie 头
session 的真正复杂点不在语法，而在它横跨 HTTP 无状态边界：一边是 PHP 脚本的内存生命周期，一边是浏览器 Cookie 的持久性，中间还夹着文件锁、GC 时机、反向代理缓存等现实约束。一个 session_start() 调不对，后面全白搭。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
