介绍
假设您的模块依赖于远程模块https://some.url/a.ts.。当您第一次编译模块时，将检索、编译并缓存a.ts。它将一直保持这种方式，直到您在一台新机器上运行您的模块(比如在生产中)或重新加载缓存(例如通过Deno缓存--例如重新加载)。但是，如果远程URL https://some.url/a.ts中的内容发生更改，会发生什么情况呢？这可能会导致您的生产模块使用与本地模块不同的依赖项代码运行。Deno避免这种情况的解决方案是使用完整性检查和锁定文件。
缓存和锁定文件
Deno可以使用一个小的JSON文件存储和检查子资源完整性。使用--lock=lock.json启用并指定锁定文件检查。要更新或创建锁，请使用--lock=lock.json--lock-write。Lock=lock.json告诉Deno要使用的锁文件是什么，而--lock-write用于将依赖散列输出到锁文件(--lock-write必须与--lock结合使用)。
Lock.json可能如下所示，根据依赖关系存储文件的散列：
{
"https://deno.land/std@0.95.0/textproto/mod.ts": "3118d7a42c03c242c5a49c2ad91c8396110e14acca1324e7aaefd31a999b71a4",
"https://deno.land/std@0.95.0/io/util.ts": "ae133d310a0fdcf298cea7bc09a599c49acb616d34e148e263bcb02976f80dee",
"https://deno.land/std@0.95.0/async/delay.ts": "35957d585a6e3dd87706858fb1d6b551cb278271b03f52c5a2cb70e65e00c26a",
...
}
典型的工作流程如下所示：
src/deps.ts
// Add a new dependency to "src/deps.ts", used somewhere else.
export { xyz } from "https://unpkg.com/xyz-lib@v0.9.0/lib.ts";
然后：
# Create/update the lock file "lock.json".
deno cache --lock=lock.json --lock-write src/deps.ts
# Include it when committing to source control.
git add -u lock.json
git commit -m "feat: Add support for xyz using xyz-lib"
git push
另一台机器的合作者 - 在一个新克隆的项目树：
# Download the project's dependencies into the machine's cache, integrity
# checking each resource.
deno cache --reload --lock=lock.json src/deps.ts
# Done! You can proceed safely.
deno test --allow-read src
运行时验证
与上面的缓存一样，您还可以在使用Deno run子命令期间使用--lock=lock.json选项，从而在运行期间验证任何锁定模块的完整性。请记住，这只针对之前添加到lock.json文件的依赖项进行验证。新的依赖项将被缓存，但不会进行验证。
您还可以进一步使用--cached-only标志来要求远程依赖项已经缓存。
Deno run--lock=lock.json--cached-only mod.ts
如果依赖关系树中存在尚未缓存的mod.ts依赖项，则此操作将失败。
