本地数据库路径曝光：history.db文件可定期备份
在如今越来越多的AI应用走向本地化部署的背景下，语音识别工具如 Fun-ASR WebUI 因其免订阅、低门槛和高可用性，正被广泛应用于会议记录、客服转写、个人笔记等场景。这类系统往往为了提升用户体验，悄悄“记住”用户的每一次操作——你上传了什么音频、识别出了哪些内容、用了哪种语言设置……这些信息不会凭空消失，而是被默默存进一个名为history.db的小文件里。
这个文件藏得并不深，就在项目目录的webui/data/history.db路径下，是一个标准的 SQLite 数据库。它让系统拥有了“记忆”，也让用户能随时回看历史记录。但问题也随之而来：既然我们能查，别人是否也能轻易拿到？
这不只是功能设计的问题，更触及了本地 AI 工具中一个常被忽视的安全盲区——数据存储路径的暴露与管理缺失。
SQLite 是一种轻量级嵌入式数据库，无需独立服务进程，单文件即可运行，因此成为许多桌面或边缘 AI 应用首选的数据存储方案。Fun-ASR WebUI 正是利用了它的这一特性，将每次语音识别的结果以结构化方式写入history.db。每条记录包含时间戳、文件名、原始文本、规整后文本、语言类型、热词配置等字段，完整还原了一次识别任务的上下文。
这种设计非常务实。相比把数据写入 JSON 文件（查询效率低、难以索引），或者连接远程 MySQL（部署复杂、依赖网络），SQLite 在本地场景下几乎是“最优解”。它支持 SQL 查询、具备 ACID 特性（原子性、一致性、隔离性、持久性）、跨平台兼容，并且备份迁移只需复制一个文件。
来看一段典型的实现代码：
import sqlite3 from datetime import datetime import os DB_PATH = "webui/data/history.db" TABLE_NAME = "recognition_history" def init_database(): conn = sqlite3.connect(DB_PATH) cursor = conn.cursor() cursor.execute(f''' CREATE TABLE IF NOT EXISTS {TABLE_NAME} ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, filename TEXT, original_text TEXT, normalized_text TEXT, language TEXT, vad_segments INTEGER, hotwords TEXT, itn_enabled BOOLEAN ) ''') conn.commit() conn.close() def save_recognition_record(filename, original_text, normalized_text, language, vad_segments, hotwords, itn_enabled): conn = sqlite3.connect(DB_PATH) cursor = conn.cursor() cursor.execute(f''' INSERT INTO {TABLE_NAME} (timestamp, filename, original_text, normalized_text, language, vad_segments, hotwords, itn_enabled) VALUES (?, ?, ?, ?, ?, ?, ?, ?) ''', ( datetime.now().strftime("%Y-%m-%d %H:%M:%S"), filename, original_text, normalized_text, language, vad_segments, ",".join(hotwords) if hotwords else "", itn_enabled )) conn.commit() conn.close() def query_history(keyword=None, limit=100): conn = sqlite3.connect(DB_PATH) cursor = conn.cursor() if keyword: query = f"SELECT * FROM {TABLE_NAME} WHERE filename LIKE ? OR original_text LIKE ? ORDER BY id DESC LIMIT ?" params = (f'%{keyword}%', f'%{keyword}%', limit) else: query = f"SELECT * FROM {TABLE_NAME} ORDER BY id DESC LIMIT ?" params = (limit,) cursor.execute(query, params) results = cursor.fetchall() conn.close() return results这段代码虽简单，却构成了整个“识别历史”功能的核心逻辑。init_database()确保表存在；save_recognition_record()在每次识别完成后自动落盘；而query_history()支持前端按关键词模糊搜索，让用户可以快速定位某段录音的内容。
从工程角度看，这套机制解决了几个实际痛点：
- 操作不可追溯：以前识别完就完了，关掉页面一切归零。现在哪怕隔了一周，也能翻出当时的转写结果。
- 避免重复识别：通过比对文件名或文本相似度，系统可以提示“该音频已处理过”，节省计算资源。
- 便于数据分析：管理员可以通过 SQL 统计高频语言、常用热词、识别时长分布，进而优化模型参数或使用习惯。
但从安全视角看，这个便利背后也埋着隐患。
最直接的风险就是路径暴露。文档里明明白白写着webui/data/history.db，意味着任何能够访问服务器文件系统的人都可能直接拷贝这个文件。如果你是在共享主机、云服务器或多用户环境中运行 Fun-ASR，而没有做好目录权限控制，那这份包含了所有识别历史的数据库，本质上就是一个“隐私富矿”。
想象一下，如果有人上传的是内部会议录音、客户访谈甚至私人对话，这些文本一旦被提取，后果不堪设想。更糟糕的是，SQLite 是通用格式，用任何 SQLite 浏览器打开就能浏览全部内容，无需密码、无需解析。
另一个容易被忽略的问题是单点故障。history.db是个单文件数据库，虽然方便备份，但也意味着一旦损坏（比如程序异常中断导致写入冲突、磁盘错误），所有历史记录可能瞬间清零。对于长期使用的团队来说，这不仅仅是数据丢失，更是工作流的断裂。
那么，我们该如何平衡便利与安全？
首先，必须做定期备份。这是最基本也是最关键的防护措施。你可以用一条简单的 cron 任务实现每日自动归档：
# 每天凌晨2点备份数据库 0 2 * * * cp webui/data/history.db /backup/fun-asr-history-$(date +\%F).db结合 rsync 或 rclone 同步到云存储，还能进一步防止本地硬盘故障带来的风险。
其次，限制数据库增长。默认情况下，记录会无限累积，久而久之可能导致查询变慢甚至性能下降。建议设置自动清理策略，只保留最近 N 条记录。例如，保留最新的100条：
DELETE FROM recognition_history WHERE id NOT IN ( SELECT id FROM recognition_history ORDER BY id DESC LIMIT 100 );也可以按时间维度清理，比如只保留7天内的数据。
再进一步，加强访问控制。如果你通过 Web 服务对外提供 Fun-ASR 功能，务必确保/data/目录不在 Web 根目录下公开暴露。Nginx 配置中应明确禁止对该路径的访问：
location /data/ { deny all; return 403; }此外，对于涉及敏感内容的场景，还可以考虑对关键字段进行本地加密。比如在写入前使用 AES 对original_text和normalized_text加密，读取时再解密显示。虽然增加了一点开销，但能有效提升静态数据的安全性。
至于并发问题，SQLite 本身支持 WAL（Write-Ahead Logging）模式，在多数轻量使用场景下足够应对多标签页同时识别的情况。但如果并发写入频繁，建议在 Python 层面加锁，避免因竞争导致数据库锁定或写入失败。
从整体架构来看，history.db实际上处于 Fun-ASR WebUI 的“数据中枢”位置：
+------------------+ +---------------------+ | Web 浏览器 | <---> | Gradio/FastAPI | | (UI: 识别历史页面) | | (请求处理路由) | +------------------+ +----------+----------+ | v +--------+---------+ | Python 后端逻辑 | | - 接收识别结果 | | - 调用 save_record()| +--------+---------+ | v +--------+---------+ | 本地数据库 | | webui/data/history.db | +--------------------+前端展示、后端处理、历史追溯，全都围绕这个小小的.db文件展开。它的存在让工具不再“一次性”，而是具备了持续服务能力。但这也提醒我们：每一个状态的留存，都是一次责任的叠加。
最终我们要意识到，本地 AI 工具的魅力在于自由与可控，但这份自由不能建立在对数据管理的漠视之上。history.db不只是一个技术细节，它是本地智能化进程中“如何对待用户数据”的缩影。
未来，或许我们可以期待更多内置机制：比如一键导出加密备份、自动云同步、基于角色的访问控制……但在那一天到来之前，开发者需要主动扛起这根弦——不仅要让系统跑起来，更要让它跑得稳、守得住。
毕竟，真正的智能，不只是听懂你说的话，更是懂得保护你没说出口的那些事。
