如何存储生成器输出值以供复用？跨平台游戏检测程序技术咨询

DevOps 小满

2026-5-25

嘿，你的跨平台游戏检测工具听起来很实用！针对生成器输出的复用存储问题，结合你现有的JSON数据库架构，我给你几个接地气的解决方案：

方案1：扩展现有JSON数据库存储生成结果

既然你已经在用JSON管理游戏元数据，直接扩展现有结构是最顺的选择，完全贴合你的现有技术栈：

如果你要存储和单个游戏绑定的生成值（比如检测状态、Steam Cloud启用情况、最后扫描时间），可以给每个游戏条目新增字段，比如：

{
  "name": "Portal 2",
  "windows_path": "C:\\Program Files\\Steam\\steamapps\\common\\Portal 2",
  "windows_steam_path": "steam://rungameid/620",
  "linux_path": "~/.steam/steam/steamapps/common/Portal 2",
  "linux_steam_path": "steam://rungameid/620",
  "detected_windows": true,
  "detected_linux": false,
  "steam_cloud_enabled": true,
  "last_scanned": "2024-05-20T14:30:00Z"
}

如果你有全局生成值（比如本次扫描的总游戏数、扫描会话ID），可以单独创建一个scan_cache.json文件来存储，结构示例：
```
{
  "last_scan_timestamp": 1716225000,
  "total_games_detected": 18,
  "scan_session_id": "7a9f2b8d-3c1e-4d5f-8a7b-2c4d6e8f0a1b"
}
```
这种方式的优势是无需引入新工具，读写逻辑和你现有的JSON操作完全一致，上手零成本。

方案2：切换到轻量级本地数据库（SQLite）

如果之后你需要处理更复杂的查询需求（比如按平台筛选已检测游戏、按扫描时间排序），SQLite会是更合适的选择——它是文件式数据库，跨平台支持完美，不需要额外的服务端：

可以设计两张关联表：一张games存储你现有的游戏元数据，另一张scan_results存储生成器的输出，用game_id关联：

-- 游戏元数据表
CREATE TABLE games (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL UNIQUE,
    windows_path TEXT,
    windows_steam_path TEXT,
    linux_path TEXT,
    linux_steam_path TEXT
);

-- 扫描结果表
CREATE TABLE scan_results (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    game_id INTEGER NOT NULL,
    detected_windows BOOLEAN NOT NULL DEFAULT 0,
    detected_linux BOOLEAN NOT NULL DEFAULT 0,
    steam_cloud_enabled BOOLEAN,
    last_scanned TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (game_id) REFERENCES games(id)
);

每次生成器运行后，只需执行INSERT或UPDATE操作更新scan_results表即可；后续复用数据时，用简单的SQL查询就能快速筛选、聚合结果，比JSON更适合复杂场景。

方案3：使用键值对格式的本地缓存文件

如果生成的结果是简单的键值映射（比如“游戏名 -> 是否检测到”），用轻量级的键值缓存文件会更轻便：

INI格式：人类可读，修改方便，适合简单数据：

[Portal 2]
detected_windows = true
detected_linux = false
steam_cloud = true
last_scanned = 2024-05-20 14:30:00

[Half-Life 2]
detected_windows = true
detected_linux = true
steam_cloud = false
last_scanned = 2024-05-20 14:31:00

序列化二进制文件：如果你的生成结果是复杂对象，比如用Python的pickle、C#的BinaryFormatter（注意安全风险）或者Go的encoding/gob直接序列化对象到文件，读写速度快，但缺点是不可读，跨语言复用难度高。

方案4：内存缓存+持久化结合

如果你的程序需要频繁复用生成值，同时又要保证重启后数据不丢失，可以采用“内存缓存+定期持久化”的模式：

把生成结果先存储在内存中的数据结构里（比如一个字典、哈希表或自定义对象），平时读取直接从内存拿，速度极快；
在程序退出时，或者每隔固定时间，把内存中的数据持久化到上面提到的JSON、SQLite或缓存文件中；
下次程序启动时，先从持久化文件加载数据到内存，继续复用。

这种方式兼顾了性能和数据持久性，适合需要高频访问生成结果的场景。

内容的提问来源于stack exchange，提问作者Alexandre Cortegaça