MANIFEST 文件不可丢弃或手动修改，它是 multi-part AOF 恢复的唯一元数据入口，记录 BASE/INCR 文件的时序、范围、校验和状态；缺失或损坏将导致 Redis 启动失败。
MANIFEST 文件是 multi-part AOF 恢复过程的唯一入口，没有它，Redis 启动时无法识别 BASE 和 INCR 文件的依赖顺序，直接报错退出。
MANIFEST 文件为什么不能丢、不能手动改
manifest 文件不是日志，而是结构化元数据清单，记录了每个 appendonly.aof.*.base.rdb 和 appendonly.aof.*.incr.aof 的生成时间、序列号、生效范围（起始 offset）、校验和及文件状态（active / obsolete）。Redis 启动时只读取 appendonly.aof.manifest，再按其中顺序加载对应文件；若 manifest 缺失或 JSON 格式损坏，Redis 会拒绝启动，并在日志中明确提示：Failed to load AOF manifest: Invalid JSON or missing required fields。
常见误操作包括：用文本编辑器手动修改 manifest、用 cp 覆盖旧 manifest、在备份恢复时漏掉该文件、或误将 appenddirname 目录整个清空。
- manifest 必须与所有 AOF 文件位于同一目录（即
appenddirname配置路径） - Redis 不会自动生成 manifest —— 它只在 AOF 重写、INCR 切换或配置变更时由内部逻辑原子写入
- 手动修复 manifest 极易出错，官方不提供工具；出问题优先考虑从最近一次完整备份恢复整个
appenddirname
如何验证 MANIFEST 是否健康且与当前 AOF 文件一致
最直接方式是用 redis-check-aof --fix 对 manifest 所列每个文件做存在性 + 可读性检查，但它不校验逻辑一致性。更稳妥的做法是：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确认
appenddirname下存在且仅存在一个appendonly.aof.manifest文件 - 用
cat appendonly.aof.manifest | jq '.'查看是否为合法 JSON，并检查version字段是否为1（Redis 7.0 当前唯一版本） - 比对 manifest 中
files数组长度与磁盘上实际*.base.rdb+*.incr.aof文件总数是否一致 - 检查最后一个 INCR 文件的
start_offset是否等于前一个文件的end_offset（允许有微小 gap，但不可倒置）
MANIFEST 如何影响故障恢复行为
当某个 INCR 文件损坏时，Redis 不会中断恢复，而是跳过该文件、继续加载后续有效文件 —— 这个“跳过”逻辑完全依赖 manifest 中的 state 和 end_offset 字段。但如果 manifest 本身把已损坏的 INCR 标记为 "state": "active"，Redis 就会尝试加载并失败；反之，若你提前把它改成 "state": "obsolete"（需确保 JSON 格式无误），Redis 就会忽略它。
注意：redis-cli CONFIG SET aof-use-rdb-preamble yes 等运行时配置变更，也会触发 manifest 重写，此时旧 manifest 会被原子替换 —— 所以任何手动干预必须在 Redis 停止状态下进行，且必须保证磁盘写入完成后再启动。
真正容易被忽略的是：manifest 文件自身没有 fsync 强制保障，如果服务器突然断电，可能只写入一半内容。因此 appenddirname 所在磁盘必须启用 write barrier 或使用支持原子写入的文件系统（如 XFS），否则 manifest 损坏概率远高于单个 INCR 文件。
