安全分析工具经常面对一个矛盾：功能越丰富，数据路径越难解释；为了效率接入在线服务，又会把敏感输入带出本机。LapCry 给出的答案是“本地优先 + 操作配方”。
操作配方不是功能清单
传统工具箱把编解码、哈希、压缩和解析分成不同入口。用户需要在多个窗口之间搬运结果，最后很难说明一次处理到底经过了哪些步骤。
配方模型把每一步明确写进处理链：一个操作接收输入、应用参数、产生输出，然后交给下一个操作。禁用、断点、单步和 Fork 让中间状态变得可观察，配方文件也让整个过程可以复现。
这类结构特别适合安全场景。分析人员不只是在追求最后的结果，还需要解释数据为什么变成现在这样。
本地边界如何落地
LapCry 的主体是 .NET 8 WinForms 桌面壳，界面运行在 WebView2 中。前端资源在首次启动时释放到本地，WebView 只允许回环页面导航，本地静态服务绑定在 127.0.0.1 的随机端口。
几个边界值得单独看：
- 输入、输出、配方与用户数据留在本机。
- 自定义 JavaScript 在隔离 Worker 中运行，网络 API 被禁用。
- 脚本执行有超时控制，Worker 超时后会被终止。
- 退出时关闭监听器并释放 WebView 资源。
- 少数主动联网操作需要用户明确触发。
这些限制并不会让工具自动获得安全性，但它们让“本地优先”从宣传语变成了架构约束。
复杂度仍在哪里
LapCry 当前仍有明确的内存占用问题。WebView2 与操作模块会带来较高空闲内存，README 中记录的工作集约为数百 MB，并已列入后续优化。
这也是工程类安全工具的真实状态：功能边界可以利用，但性能、资源生命周期和异常清理始终需要继续验证。