session 默认支持直接存储整型，无需转字符串；php 自动序列化并保持类型，读取时仍为 integer，常见错误是手动转字符串导致后续类型判断或函数调用失败。
Session 默认就能存整型，不用转字符串
PHP 的 $_SESSION 是个普通数组，底层用序列化存储，但你完全不需要手动 serialize() 或 strval()。直接赋值 $_SESSION['count'] = 42; 就行——PHP 会自动处理类型保留，读出来还是 int。
常见错误现象：有人把整数转成字符串再存，比如 $_SESSION['id'] = (string)$uid;，结果后续用 === 判断或传给需要 int 的函数（如 mysqli_query()）时出错。
- 使用场景：登录后存用户 ID、购物车商品数量、分页页码等纯数值状态
- 参数差异：无需额外配置；但确保
session_start()已调用，且不在输出之后调用 - 性能影响：无额外开销；比手动转字符串 +
intval()再转回更轻量
为什么 var_dump($_SESSION) 有时显示 string？
这不是类型丢失，而是你看到的是 session 存储文件（或 Redis/Memcached 后端）里的原始序列化内容，不是运行时的 PHP 变量。真正从 $_SESSION 读出来的值，gettype() 一定是 integer。
容易踩的坑：在调试时直接 file_get_contents(session_save_path().'/sess_'.session_id()) 查看内容，发现里面是 s:2:"42"; 就以为存成了字符串——其实这只是序列化表示，反序列化后仍是整型。
立即学习“PHP免费学习笔记（深入）”；
- 验证方法：用
var_dump(gettype($_SESSION['count']));看输出是否为string(7) "integer" - 兼容性影响：PHP 5.6+ 和 7.x/8.x 行为一致；旧版 PHP 5.3 也支持原生整型存储
session.auto_start = 1 时整型存储是否可靠？
可靠，但不推荐开启 session.auto_start。它会在脚本开头自动执行 session_start()，看似省事，实则埋雷：
- 如果任何输出（包括 BOM、空格、echo）出现在它之前，会触发
headers already sent错误 - 无法控制 session 启动时机，比如你想先检查请求头再决定是否启动 session
- 对整型存储本身没影响，但错误导致 session 未启动，
$_SESSION就写不进去——你以为存了，其实根本没生效
建议始终显式调用 session_start()，放在 <?php 标签后第一行，且确认没有前置输出。
用 Redis 当 session handler 时 int 还能原样读出来吗？
能，前提是 Redis 扩展版本 ≥ 5.3.0 且 PHP ≥ 7.0。老版本（如 phpredis 3.x + PHP 5.6）在某些配置下可能把所有值当字符串存，导致取出来是 string 类型。
验证方式很简单：$_SESSION['x'] = 123; session_write_close(); session_start(); var_dump($_SESSION['x'], gettype($_SESSION['x'])); —— 输出应为 int(123) 和 string(7) "integer"。
- 关键配置项：
session.save_handler = redis，session.save_path = "tcp://127.0.0.1:6379?database=1" - 容易被忽略的点：Redis 中实际存储的是 PHP 序列化字符串，类型信息包含在内；不是靠 Redis 的数据类型（如 INT）保证，而是靠 PHP 反序列化逻辑
session_write_close() 又忘了重新 session_start()。 
