生产环境必须源码编译+systemd管理，因apt版redis版本滞后、配置混乱、不支持include、权限/路径不统一、升级易覆盖配置；需指定prefix安装、设supervised systemd、requirepass强密码并严格配置顺序。
redis-server 能直接运行，但生产环境必须走源码编译 + systemd 管理，否则后续改配置、加密码、开机自启全会踩坑。
为什么不用 apt install redis-server
Debian/Ubuntu 仓库里的 Redis 版本普遍滞后（比如 Ubuntu 22.04 默认装的是 6.0.x），而 7.x 已成主流，新特性如 ACL、Redis Functions、更细粒度的内存淘汰策略都不可用。更重要的是，包管理器安装的配置路径、用户权限、日志位置不统一，/etc/redis/redis.conf 和实际运行时加载的配置常对不上，改完 requirepass 却连不上，第一反应就是“密码没生效”，其实是服务根本没 reload 那个文件。
- 仓库版 Redis 不支持
redis.conf中的include指令（7.0+ 引入），无法拆分配置 - systemd 服务文件硬编码了
User=redis，但包安装未必创建该用户，导致启动失败且报错模糊（Failed at step USER spawning） - 升级困难：
apt upgrade可能覆盖你手动改过的配置，或干脆拒绝升级（因配置文件被修改）
make install 前必须设 PREFIX
默认 sudo make install 会把 redis-server、redis-cli 全塞进 /usr/local/bin——看着方便，实则埋雷：多个版本共存时无法区分，卸载只能靠 rm -f 盲删，极易误伤其他软件；更麻烦的是，systemd 服务文件里写死二进制路径，一旦重装没指定 PREFIX，旧服务就指向不存在的文件，systemctl start redis-server 直接报 not found。
- 推荐固定路径：
sudo make install PREFIX=/usr/local/redis-7.2.5 - 装完立刻验证：
ls /usr/local/redis-7.2.5/bin/应看到redis-server、redis-cli等 - 别用软链模拟多版本——
ln -sf /usr/local/redis-7.2.5 /usr/local/redis看似优雅，但systemd读取ExecStart时不会解析软链目标，升级后仍需手动改服务文件
supervised systemd 是守护进程唯一可靠写法
daemonize yes 是过时方案。它让 redis-server 自己 fork 子进程并退出父进程，systemd 完全感知不到子进程生命周期，systemctl status redis-server 显示 active (exited)，journalctl -u redis-server 查不到日志，崩溃后也不会自动拉起。
- 必须改配置项：
supervised no→supervised systemd，同时确保daemonize no（保持默认） - 对应 systemd 服务文件中
Type=notify不可少，否则 systemd 认为服务没准备好，After=network.target失效 - 若跳过这步，
systemctl enable redis-server表面成功，重启后服务静默死亡，只留一个空进程 ID 文件在/var/run/redis.pid
protected-mode no 和 bind 0.0.0.0 必须配密码
开远程访问不是改两行配置就完事。protected-mode no 关掉保护模式后，Redis 会监听所有 IPv4 接口，但若没设 requirepass，任何能连上服务器的人都能执行 FLUSHALL 清空数据——这不是理论风险，是真实发生过的批量删库事件。
- 顺序不能错：先写
requirepass YourStrongPass!2026，再改bind 0.0.0.0和protected-mode no - 密码必须含大小写字母+数字+符号，长度 ≥12；避免用
redis、123456这类字典词 - 改完配置后，必须
sudo systemctl restart redis-server，而不是killall redis-server && redis-server /etc/redis/redis.conf，后者绕过 systemd 管理，下次 reboot 仍无效
supervised systemd 和 PREFIX 这两个点，90% 的线上故障都源于忽略它们。
