必须同时调低$cfg['LoginCookieValidity']和session.gc_maxlifetime，且前者≤后者，否则phpMyAdmin会自动降级为1440秒并报错；常见失效原因是仅改phpMyAdmin配置而未同步调整PHP底层session回收策略。
必须同时调低两个参数，且 $cfg['LoginCookieValidity'] 必须 ≤ session.gc_maxlifetime，否则会直接报错并强制降级为 1440 秒。
为什么改了 $cfg['LoginCookieValidity'] 没生效？
常见错误是只改了 phpMyAdmin 配置，却没同步调整 PHP 底层会话回收策略。phpMyAdmin 启动时会校验：$cfg['LoginCookieValidity'] 是否超过 session.gc_maxlifetime，一旦越界，它就自动放弃你的设置，回退到默认的 1440 秒，并在页面顶部显示红色警告：“您的 PHP 配置参数 session.gc_maxlifetime 短于您在 phpMyAdmin 中设置的 Cookies 有效期……”
这个校验发生在每次请求入口，不是只在登录时检查——意味着哪怕你已经登录成功，只要这两个值不匹配，后续所有操作都运行在“被降级”的会话下，随时可能中断。
- 先确认当前 PHP 的
session.gc_maxlifetime值：创建info.php，写<?php phpinfo(); ?>，访问后搜索 “session.gc_maxlifetime” - 修改对应 PHP 版本的
php.ini（注意：宝塔、Docker、AppServer 环境路径各不相同，不能只改系统全局 php.ini） - 设为比如
1800（30 分钟），保存后必须重启php-fpm或对应 PHP 进程，service php-fpm restart不一定覆盖所有实例
如何安全地在 config.inc.php 中设置更短的 Cookie 有效期？
不要碰 config.default.php —— 它是只读模板，升级时会被覆盖。所有自定义配置必须写进 config.inc.php（若不存在，复制 config.sample.inc.php 并重命名）。
立即学习“PHP免费学习笔记（深入）”；
在该文件末尾添加：
$cfg['LoginCookieValidity'] = 1800; $cfg['LoginCookieStore'] = 0;
$cfg['LoginCookieStore'] = 0 表示不强制浏览器本地持久化 cookie，完全依赖服务端 session 生命周期，这对缩短超时更可控；设为 1 会让 cookie 写入硬盘，反而可能绕过服务端限制。
- 值必须是整数秒，不能带单位（如不能写
30m） - 不要加注释符号
//在同一行，phpMyAdmin 解析器对格式敏感 - 如果使用宝塔多站点，每个 phpMyAdmin 站点都要进各自根目录单独改，不能只改一个
AppServer 或容器环境里 session 突然丢失怎么办？
这类环境常默认用文件存 session（session.save_handler = files），但并发高或磁盘满/权限异常时，sess_* 文件可能写失败或被清理，导致用户输入正确密码后瞬间跳回登录页，无任何错误提示。
这不是超时问题，而是 session 根本没存住。排查重点：
- 检查
session.save_path目录是否存在、可写、空间充足（如/var/lib/php/session） - 确认
session.save_handler是否被意外改成redis或memcached，但后端服务未运行 - AppServer 下建议显式指定安全路径：
session.save_path = "/tmp/php-sessions"，并chown www-data:www-data /tmp/php-sessions - 若用 Redis，确保
redis-cli ping可通，且connect-redis初始化时传了ttl参数，否则 key 永不自动过期
最易被忽略的一点：phpMyAdmin 的会话超时控制本质是「客户端 cookie 过期 + 服务端 session 存活」双重判定，二者缺一不可。很多人只盯着 $cfg['LoginCookieValidity']，却忘了 session 数据本身是否还在存储里——尤其在共享存储或分布式部署中，session 存储的可靠性比 cookie 设置更重要。
