SQLite日志机制深度解析：WAL与回滚日志的原理、选择与实战调优

1. 项目概述：为什么SQLite的日志机制值得深挖？

如果你用过SQLite，大概率会觉得它就是个“轻量级文件数据库”，开箱即用，事务支持也还行。但当你真正把它用在生产环境，或者在高并发、需要断电恢复的场景下，可能就会遇到一些“诡异”的问题：为什么数据库文件突然损坏了？为什么事务回滚后数据状态不对？为什么并发写入性能上不去？这些问题，十有八九都跟SQLite的日志机制脱不开干系。

SQLite的日志，远不止一个简单的“操作记录”文件。它是整个数据库ACID（原子性、一致性、隔离性、持久性）特性的基石，是保证数据在系统崩溃、程序异常甚至断电后依然能保持一致的“安全气囊”。很多人只知其然，会用BEGIN TRANSACTION和COMMIT，却不知其所以然，更不清楚背后是“回滚日志”还是“预写式日志”在默默工作。这就像开车只懂踩油门和刹车，却不了解ABS和ESP系统，一旦遇到湿滑路面，就容易失控。

本文将从一个资深开发者的视角，彻底拆解SQLite的日志机制。我们不只讲概念，更会深入到文件格式、工作流程、配置参数和实战踩坑经验。你会明白“WAL模式”和“回滚日志模式”的本质区别，知道如何根据你的应用场景（嵌入式设备、桌面应用、中等负载服务端）做出正确选择，并学会如何通过日志来诊断和修复数据库问题。无论你是移动应用开发者、桌面软件工程师，还是物联网设备的固件程序员，理解这些内容都将让你对SQLite的掌控力提升一个档次。

2. SQLite日志的核心：两种模式的哲学与实现

SQLite主要提供了两种事务日志机制：回滚日志和预写式日志。这不仅仅是两种技术实现，更代表了两种不同的设计哲学和适用场景。默认情况下，SQLite使用回滚日志模式，这也是最经典、兼容性最好的模式。

2.1 回滚日志模式：经典的“影子分页”策略

回滚日志是SQLite的“元老”。它的核心思想是“先备份，再修改”。你可以把它想象成玩一个不能存档的游戏时，在挑战Boss前手动把游戏存档文件复制一份。如果挑战失败（事务回滚或系统崩溃），就用备份文件覆盖回来，一切恢复原状。

2.1.1 工作流程与文件操作

当一个事务开始时（例如执行BEGIN TRANSACTION），SQLite会进行以下关键操作：

1. 创建日志文件：在数据库文件（比如test.db）所在的目录，创建一个名为test.db-journal的回滚日志文件。这个文件是事务存在的标志。
2. 写入日志头：日志文件的开头会写入一个特殊的“日志头”，其中包含数据库页面的原始大小、随机数（用于防止误用旧的日志文件）等信息。
3. 备份原始页：在事务修改任何一个数据库页面之前，SQLite会先将该页面的原始内容完整地写入回滚日志文件。这确保了我们有能力将页面回滚到事务开始前的状态。
4. 修改内存与数据库：事务中的INSERT、UPDATE、DELETE操作会先在内存中的页面缓存（page cache）里进行。当事务提交（COMMIT）时，这些被修改的“脏页”才会被写回数据库文件。
5. 提交与清理：提交过程是关键。
   • 阶段一（写入）：首先，将所有脏页从内存刷入数据库文件。注意，此时数据可能还在操作系统的磁盘缓存中，并未真正落盘。
   • 阶段二（同步）：然后，强制将数据库文件同步到物理磁盘（调用fsync或类似系统调用），确保修改持久化。
   • 阶段三（删除）：最后，删除回滚日志文件（test.db-journal）。删除日志文件这个动作，才是事务提交成功的最终标志。如果系统在删除日志文件前崩溃，下次打开数据库时，SQLite会发现这个日志文件，并自动执行回滚操作，撤销未完成的事务。

注意：这里有一个非常重要的细节。在步骤5的阶段一和阶段二之间，如果系统崩溃，数据库文件可能处于“部分更新”的不一致状态。但正因为日志文件还存在，SQLite在恢复时可以用日志文件中的原始页面内容，覆盖数据库文件中被部分修改的页面，从而恢复一致性。这就是“原子提交”的实现。

2.1.2 模式特点与适用场景

• 优点：
  • 原理简单直观，易于理解和调试。
  • 兼容性极佳，是所有平台和版本的默认支持模式。
  • 单个写入者性能尚可，在串行化写入的场景下，效率不错。
• 缺点：
  • 写入者阻塞读取者：当一个写事务正在进行时（日志文件存在），其他读事务可能会被阻塞，直到写事务完成。这是因为SQLite需要保证读事务看到的是一个一致的数据快照。
  • 并发能力弱：本质上不支持真正的读写并发。多个连接同时写入需要严格的锁机制来序列化，成为性能瓶颈。
  • fsync调用频繁：每次提交事务都需要至少两次fsync（一次对日志文件，一次对数据库文件），在机械硬盘上这是非常耗时的操作。

适用场景：对并发要求极低的嵌入式系统、单用户桌面应用程序、配置存储、或作为应用内缓存数据库。在这些场景下，其简单性和可靠性是首要优势。

2.2 WAL模式：颠覆性的“写时复制”策略

预写式日志模式是SQLite 3.7.0引入的革命性特性。它彻底颠倒了回滚日志的逻辑，从“先备份，再修改”变成了“先记录修改，再合并”。你可以把它想象成Git的工作流：你在一个独立的分支（WAL文件）上进行所有修改，主分支（数据库文件）保持不变。其他人都可以继续读取主分支。等你修改完成后，再一次性将分支合并到主分支上。

2.2.1 工作流程与核心文件

WAL模式下，关键文件变成了两个：

• 数据库文件：主数据文件，内容相对稳定。
• WAL文件：通常名为test.db-wal。它是一个只追加的日志文件，所有的事务修改都首先以“帧”的形式记录在这里。

其工作流程如下：

1. 修改写入WAL：事务开始后，所有的修改（INSERT/UPDATE/DELETE）不再直接写入数据库文件，而是被转换成一系列“日志记录”，追加到WAL文件的末尾。每个日志记录对应一个页面的修改。
2. 提交即生效：当事务提交时，SQLite只是在WAL文件中写入一个特殊的“提交标记”。一旦这个标记写入WAL文件，事务就被视为已提交，数据立即对所有后续的读操作可见。这个过程通常很快，因为它只涉及对WAL文件的追加写入，且不一定需要立即fsync。
3. 读取数据：读操作如何看到最新数据？SQLite会维护一个“WAL索引”在共享内存中。当读取一个页面时，SQLite首先检查WAL文件中是否有该页面的更新版本。如果有，就从WAL文件中读取；如果没有，才从原始的数据库文件中读取。这使得读写可以完全并发。
4. 检查点：WAL文件不能无限增长。后台会有一个“检查点”进程，负责将WAL文件中已提交的修改，批量地、顺序地写回数据库文件。检查点完成后，WAL文件头部的一个标记会被更新，表示这部分日志已经“归档”，可以被覆盖重用。

2.2.2 模式特点与适用场景

• 优点：
  • 读写高并发：这是最大的优势。一个连接在写入WAL文件时，其他连接可以毫无阻塞地读取数据库（从数据库文件或WAL文件中读取一致的数据快照）。
  • 写入性能更高：多数写入操作只是顺序追加到WAL文件，比随机写入数据库文件更快。提交操作也更快，因为不需要立即fsync数据库文件。
  • fsync更少：检查点过程可以批量同步数据到数据库文件，减少了fsync的调用频率。
• 缺点：
  • 复杂性高：需要维护WAL文件和共享内存索引，实现更复杂。
  • 需要共享内存：在无法创建共享内存的某些特殊文件系统（如网络文件系统NFS）上，WAL模式可能无法工作或性能下降。
  • 数据库文件不是“最新”的：在检查点完成前，数据库文件的内容是滞后的。直接拷贝数据库文件可能无法得到最新数据，必须同时拷贝WAL文件。
  • VACUUM操作更慢：在WAL模式下执行VACUUM（整理数据库空间）需要临时切换回回滚日志模式，过程更复杂。

适用场景：需要较高读写并发的应用，如多线程桌面应用、轻量级Web服务器后端、移动应用（特别是Android，其内置的Room库默认就使用WAL）、以及任何有多个连接同时读写的场景。

2.3 模式选择：一张表看清本质

为了帮你快速决策，我将两种模式的核心差异总结如下：

特性维度	回滚日志模式	WAL模式
核心思想	修改前备份（Copy-on-Write）	修改日志化，延迟合并（Write-Ahead Logging）
关键文件	-journal	-wal和-shm（共享内存文件）
读写并发	差。写事务会阻塞读。	优秀。读写互不阻塞，写写仍需序列化。
写入性能	一般。涉及随机写和多次fsync。	通常更好。顺序追加写，fsync更少。
恢复速度	快。只需应用或丢弃一个日志文件。	可能较慢。需要回放整个WAL文件。
兼容性	最好。所有环境默认支持。	好。但某些特殊文件系统（如NFS）可能有问题。
备份热度	容易。直接拷贝单个.db文件即可。	较复杂。需同时拷贝.db和.wal文件，或用备份API。
推荐场景	单线程/单连接应用、嵌入式设备、配置存储。	多线程应用、客户端缓存、中等负载服务端。

实操心得：对于绝大多数现代应用，尤其是移动端和桌面端，我强烈建议默认启用WAL模式。它的并发优势带来的收益远大于其复杂性。你可以在连接数据库后立即执行一条SQL命令来开启它：PRAGMA journal_mode=WAL;。在Android的Room或SQLiteOpenHelper中，通常已经在配置中默认开启了。

3. 日志机制的魔鬼细节：配置、文件与恢复原理

理解了两种模式的宏观区别，我们还需要深入微观层面，看看那些影响稳定性、性能和可靠性的关键配置与实现细节。

3.1 关键PRAGMA设置解析

SQLite通过PRAGMA命令提供了一系列控制日志行为的设置。用对了是神器，用错了就是坑。

3.1.1journal_mode：选择你的日志策略

这是最核心的设置。除了DELETE（默认的回滚日志）和WAL，还有其他几种模式：

• TRUNCATE：与DELETE类似，但在提交时不是删除日志文件，而是将其截断为0字节。在某些文件系统上，截断操作比删除更快。
• PERSIST：提交时不清除日志文件内容，只是将文件头清零。这可以避免文件系统的目录项操作，在某些场景下可能提升速度，但会留下日志文件。
• MEMORY：将日志保存在内存中而非磁盘。性能极高，但事务不具备持久性（Durability）。系统崩溃或程序退出，未提交的事务会丢失。仅用于临时数据库或可以接受数据丢失的缓存场景。
• OFF：完全禁用日志。这意味着原子提交和崩溃恢复也被禁用。数据库可能因崩溃而损坏。除非你非常清楚自己在做什么（例如操作一个临时、可丢弃的数据库），否则绝对不要使用。

注意：TRUNCATE和PERSIST是DELETE模式的变体，旨在优化某些文件系统下的性能。但在使用SSD的主流现代系统上，它们的优势已不明显，DELETE通常是更安全简单的选择。MEMORY和OFF是危险选项，请慎用。

3.1.2synchronous：在速度与安全间走钢丝

这个设置控制SQLite何时强制将数据刷入磁盘（调用fsync）。它直接关系到数据安全性和性能。

• FULL：最安全。在回滚日志模式下，确保日志文件和数据库文件都在事务提交前刷盘；在WAL模式下，确保WAL文件的提交记录刷盘。这是保证数据在电源故障后不丢失的最低要求。对于需要强一致性的数据，必须使用FULL。
• NORMAL：折中。在回滚日志模式下，只同步日志文件，不同步数据库文件；在WAL模式下，只定期同步WAL文件。这能提升性能，但若在数据库文件写入后、日志文件删除前发生崩溃，数据库可能损坏。
• OFF：最危险。SQLite将数据交给操作系统后就直接返回，完全依赖操作系统的缓存策略。性能最快，但一旦系统崩溃，数据几乎必定损坏或丢失。仅用于临时数据库或可完全重建的缓存。

我的建议：对于生产环境或重要数据，永远使用PRAGMA synchronous=FULL;。性能的损失可以通过合理的事务批处理和使用WAL模式来弥补。数据丢失的成本远高于那一点性能。

3.1.3journal_size_limit与wal_autocheckpoint

• journal_size_limit：设置回滚日志文件的最大大小（字节）。防止单个事务过大导致日志文件撑满磁盘。对于不可预测的大事务，设置此值是个好习惯。
• wal_autocheckpoint：WAL模式专用。设置自动触发检查点的WAL文件帧数阈值。默认值是1000。增大此值可以减少检查点频率，提升写入性能，但会增加WAL文件大小和崩溃恢复时间。通常保持默认即可。

3.2 日志文件格式探秘

了解文件格式有助于你在出问题时进行低级调试或数据恢复。

3.2.1 回滚日志文件格式

一个完整的回滚日志文件包含：

1. 日志头：固定大小（通常为28字节），包含魔数（标识文件类型）、数据库页面大小、数据库文件修改计数、随机数等。这个随机数至关重要，它必须与数据库文件头中的随机数匹配，SQLite才会认这个日志文件，防止误用其他数据库的旧日志。
2. 页面备份：紧接着日志头，按顺序存储了被修改页面的原始内容。每个页面备份以其在数据库中的页号开头。
3. 日志结束标记：可能包含一个特殊的页号（通常为0）表示日志结束。

当SQLite进行崩溃恢复时，它会读取日志文件，验证头部的随机数与数据库文件匹配，然后按顺序将日志中的页面内容写回数据库文件的对应位置，从而撤销不完整事务的修改。

3.2.2 WAL文件格式

WAL文件是一个帧序列：

1. WAL头：包含魔数、版本、数据库页面大小、检查点信息等。
2. 帧：每个帧对应一个被修改的数据库页面。一帧包含：
   • 帧头：页号、该页在事务中的提交序列号、盐值（用于校验）等。
   • 页面数据：该页面的完整新内容。
3. 提交标记：当一个事务提交时，其最后一帧的帧头中会设置一个“提交”标志。

WAL索引（-shm文件）是一个共享内存区域，它不存储实际数据，而是存储了WAL文件中帧的索引信息，帮助SQLite快速定位某个页面最新的帧在WAL文件中的位置。

3.3 崩溃恢复流程详解

这是日志机制价值的终极体现。我们分模式来看：

3.3.1 回滚日志模式的恢复

1. 启动检测：SQLite打开数据库时，会检查同目录下是否存在-journal文件。
2. 日志验证：如果存在，读取日志头，验证魔数、页面大小和随机数是否与当前数据库文件匹配。如果不匹配（例如是别的数据库的旧日志），则直接删除该日志文件。
3. 热日志与冷日志：
   • 热日志：如果日志文件存在且有效，数据库文件可能处于不一致状态。SQLite会执行“回滚恢复”，将日志中备份的原始页面写回数据库，撤销未完成的事务。
   • 冷日志：如果日志文件存在，但数据库文件的修改计数与日志头中的信息表明上一个事务已成功提交（只是日志没来得及删除），SQLite会执行“提交恢复”，实际上什么都不做，然后删除日志文件。这种情况发生在提交过程的阶段二之后、阶段三之前崩溃。
4. 清理：恢复完成后，删除日志文件。

3.3.2 WAL模式的恢复

1. 读取WAL头：打开数据库时，SQLite会读取WAL文件的头部信息。
2. 回放WAL：SQLite会从数据库文件记录的最后一次成功检查点的位置开始，读取WAL文件中的帧，并将这些帧中的页面修改应用到数据库文件中。这个过程称为“WAL回放”。
3. 更新数据库头：回放完成后，更新数据库文件头中的信息，标记新的文件状态。
4. 重置WAL：WAL文件可以被重置（文件内容清空但保留），以便重用。

WAL恢复的优势在于，它是一个幂等的操作。即使恢复过程被中断，再次启动时重新执行一遍即可，不会造成额外损坏。

4. 实战：配置、监控与性能调优

理论说得再多，不如动手实操。这一部分，我们来看如何在实际项目中应用和优化SQLite的日志机制。

4.1 模式切换与配置实践

开启WAL模式：

-- 在连接数据库后立即执行 PRAGMA journal_mode=WAL;

执行后会返回wal，表示切换成功。这是一个持久化设置，会被记录在数据库文件中，下次打开依然有效。

设置安全同步级别：

PRAGMA synchronous=FULL; -- 强烈推荐用于生产数据

管理检查点：

-- 手动执行检查点，将WAL中的所有已提交帧写回数据库 PRAGMA wal_checkpoint(FULL); -- FULL模式会阻塞直到检查点完成 -- PRAGMA wal_checkpoint(PASSIVE); -- PASSIVE模式尽可能多执行，但不阻塞 -- PRAGMA wal_checkpoint(RESTART); -- 类似FULL，并尝试重置WAL文件 -- 查询当前WAL文件状态 PRAGMA wal_checkpoint(TRUNCATE); -- 这是一个查询操作，返回（忙帧数，日志帧数，检查点帧数）

实操心得：对于有固定维护窗口的应用（如夜间），可以在空闲时手动执行PRAGMA wal_checkpoint(FULL);来重置WAL文件，保持其大小可控。对于7x24运行的服务，可以设置PRAGMA wal_autocheckpoint=1000;（或更大）并让SQLite自动管理。

4.2 监控日志状态与性能

如何知道你的日志系统是否健康？

查看当前日志模式：

PRAGMA journal_mode;

查看WAL文件信息：

# 使用sqlite3命令行工具 sqlite3 your_database.db sqlite> PRAGMA wal_checkpoint(TRUNCATE); -- 输出类似：0|100|50 -- 第一个数字：繁忙的帧数（通常为0） -- 第二个数字：WAL文件总帧数 -- 第三个数字：最后一个检查点完成的帧数 -- 如果第一个数很大，说明有长时间未提交的写事务。 -- 如果第二个数远大于第三个数，说明检查点滞后，WAL文件在增长。

监控文件大小：定期检查-wal和-shm文件的大小。一个持续增长的WAL文件可能意味着：

1. 有非常长的读事务（阻止了检查点）。
2. 写入吞吐量极高，检查点跟不上。
3. 数据库处于只读模式，检查点被禁用。

4.3 性能调优指南

1. 使用事务批处理：这是提升SQLite写入性能最有效的手段。将多条INSERT/UPDATE语句放在一个事务中，可以避免为每条语句都创建/提交日志，减少磁盘I/O。

   • 错误示范：循环执行1000次INSERT INTO table VALUES (...)
   • 正确示范：BEGIN;执行1000次INSERT；COMMIT;

2. 调整页面大小：PRAGMA page_size。更大的页面大小（如4096字节）可以减少I/O次数，尤其对涉及大量顺序扫描的查询有利。但必须在创建数据库之前设置，且一旦设置无法更改（除非VACUUM）。

3. 合理设置缓存大小：PRAGMA cache_size = -kibibytes;。设置SQLite可以缓存的数据库页面数。更大的缓存能减少磁盘读取。通常设置为内存的合理比例（如几万到几十万页）。

4. 针对WAL模式的优化：

   • 增加wal_autocheckpoint：如果写入是爆发式的，可以适当增大此值（如5000），减少检查点频率，提升写入峰值性能。
   • 在空闲期手动检查点：在应用低峰期（如午夜）调用PRAGMA wal_checkpoint(FULL);，可以控制WAL文件大小，避免其无限增长。
   • 注意长时间读事务：一个保持了很久的读事务会阻止WAL文件被回收，导致其膨胀。确保读事务及时关闭。

5. 针对回滚日志模式的优化：

   • 几乎无解。主要优化方向就是减少写事务的频率（批处理）和大小。

5. 常见问题排查与修复实录

即使理解了原理，在实际操作中依然会遇到各种问题。下面是我在多年实践中总结的一些典型案例和解决方法。

5.1 数据库文件损坏与日志恢复

问题现象：打开数据库时出现SQLITE_CORRUPT错误，或提示“database disk image is malformed”。

可能原因与排查：

1. 日志文件残留：这是最常见的原因。系统崩溃导致一个-journal或-wal文件被遗留下来。
   • 排查：检查数据库文件同级目录下是否有孤立的-journal或-wal、-shm文件。
   • 解决：不要手动删除！尝试用SQLite命令行工具打开该数据库文件。SQLite会自动触发恢复流程。如果恢复失败，可以尝试备份这些文件后，用.dump命令导出SQL语句，再导入一个新的数据库。
2. synchronous=OFF导致的数据不一致：如果为了性能关闭了同步，崩溃后数据库很可能损坏。
   • 解决：从备份恢复。没有其他好办法。这再次强调了FULL同步的重要性。
3. 文件系统错误或磁盘坏道。
   • 排查：使用操作系统工具检查磁盘健康状态。
   • 解决：修复文件系统，从备份恢复数据。

修复尝试步骤：

# 1. 尝试让SQLite自动恢复（适用于日志残留） sqlite3 corrupted.db # 如果自动打开成功，立即执行备份 .output backup.sql .dump .exit # 2. 如果自动打开失败，尝试使用`.recover`命令（SQLite 3.29.0+） sqlite3 corrupted.db '.recover' | sqlite3 recovered.db # `.recover`会尝试从损坏的文件中提取尽可能多的数据。 # 3. 使用第三方工具 # 有一些开源工具如`sqlite3_analyzer`或商业工具可以尝试修复，但成功率不保证。

重要警告：在尝试任何修复操作前，务必先对原始损坏的数据库文件进行完整备份。修复过程可能会使情况变得更糟。

5.2 WAL文件无限增长

问题现象：-wal文件变得非常大（几个GB），甚至撑满磁盘。

原因分析：

1. 长时间运行的读事务：这是头号原因。一个开启了BEGIN TRANSACTION的查询如果一直不结束（比如挂在某个长循环里），它会阻止SQLite回收旧的WAL帧。
2. 极高的写入负载：写入速度持续超过检查点进程合并数据到主数据库的速度。
3. 检查点被禁用：在只读模式或某些配置下，检查点不会自动运行。

解决方案：

1. 查找并结束长事务：检查应用代码，确保所有事务（尤其是读事务）都在完成后及时提交或回滚。使用连接池时，确保归还连接前事务状态是干净的。
2. 手动执行检查点：在业务低峰期，连接数据库并执行PRAGMA wal_checkpoint(FULL);。
3. 调整wal_autocheckpoint：如果写入是持续的，可以适当减小该值，让检查点更频繁地发生。
4. 监控与告警：编写脚本定期检查WAL文件大小，超过阈值时发出告警。

5.3 “数据库被锁定”问题

问题现象：在回滚日志模式下，并发读写时频繁出现SQLITE_BUSY或SQLITE_LOCKED错误。

原因分析：回滚日志模式下，写事务需要获取数据库的排他锁。在获取过程中，会先获得一个预留锁，此时其他写事务会被阻塞。如果读事务在写事务获取排他锁之前就开始了，它可以继续读，但会阻止写事务升级到排他锁，从而导致写事务超时失败。

解决方案：

1. 切换到WAL模式：这是根治此问题的最佳方案。WAL模式下读写锁分离，从根本上避免了此类锁竞争。
2. 优化事务粒度：如果无法使用WAL，则尽量缩短写事务的持有时间，做到“快进快出”。
3. 使用忙时重试逻辑：在代码中捕获SQLITE_BUSY异常，等待一段随机时间后重试操作。

   # Python示例 import sqlite3 import time import random def execute_with_retry(db, sql, max_retries=5): for i in range(max_retries): try: db.execute(sql) db.commit() return except sqlite3.OperationalError as e: if 'locked' in str(e) or 'busy' in str(e): wait_time = (2 ** i) + random.random() # 指数退避 time.sleep(wait_time) else: raise raise Exception('Max retries exceeded')

5.4 在多进程环境下使用WAL

问题：WAL模式依赖共享内存（-shm文件）在多连接间同步状态。在网络文件系统上，共享内存可能无法正常工作，导致性能下降或错误。

建议：

1. 避免在网络文件系统上使用WAL。如果数据库文件必须放在NFS等网络存储上，考虑使用回滚日志模式。
2. 如果必须用，确保所有进程都来自同一台主机，并且能访问相同的本地文件系统路径。
3. 考虑使用客户端-服务器架构，让单个进程（服务器）管理数据库，其他进程通过IPC/RPC与之通信，而不是直接访问数据库文件。

理解SQLite的日志机制，从“会用”到了解其“所以然”，是你从SQLite使用者进阶为掌控者的关键一步。它不再是一个黑盒，而是一个你可以根据具体场景进行观察、诊断和调优的精密系统。无论是为了追求极致的并发性能而切换到WAL，还是为了确保数据万无一失而坚守FULL同步，你的每一个选择都将基于扎实的理解，而非猜测。下次当你的数据库出现问题时，希望你能自信地打开那个日志文件，或者检查一下WAL的状态，因为你知道，问题的答案很可能就藏在里面。