企业官网建设流程全解析

LightCraft 浏览器版：3 MB 就能跑起来的零安装网页修图

【免费下载链接】lightcraftLightCraft: An open-source non-destructive photo editor written by scratch in pure Rust项目地址: https://gitcode.com/gh_mirrors/li/lightcraft

LightCraft 是一个纯 Rust 编写的开源 Lightroom 级照片管理与 RAW 开发工具，它的浏览器版把整套引擎编译成 WebAssembly：修图引擎 brotli 压缩后只有 3 MB，导入、拖滑杆、导出全程无需安装任何软件。同一套 UI、同一套修图引擎在网页里完整跑通，图库则持久化在你的浏览器存储中。

本地跑起来，只需要一条命令

先装好wasm32-unknown-unknown编译目标，再执行cargo xtask web --serve，浏览器打开http://127.0.0.1:8080/就是完整应用。入口逻辑在 xtask/web.rs，它会顺手生成 gzip / brotli 预压缩副本；加--dev参数可以编译更快，代价是运行更慢。

为什么在浏览器里拖滑杆不卡？

秘密在于"同一套代码换了个地方跑"。桌面版 egui 界面被编译成 WASM、用 WebGL2 绘制；修图与导出复用的还是 lightcraft-engine 引擎。渲染不占主线程——最多 4 个 Web Worker 各自加载同一个模块并行处理，界面因此保持跟手。整套网页应用入口在 apps/lightcraft-web。

照片存在哪？

网页版没有服务器，一切都在浏览器里。新建图库自带演示照片；原片按内容哈希存放，删掉浏览器数据，图库就没了——这也是后面要讲备份的原因。

安全机制很务实：Web Locks API 保证同一时间只有一个标签页打开图库，第二个标签页会直接提示"已在其他标签页打开"；存储写满时，命令会明确告诉你"已保存在内存但未写入"，并每 2 秒自动重试。实现细节在 store.rs。应用还会主动请求navigator.storage.persist()，降低存储被浏览器清理的概率。

换浏览器、换域名，图库怎么带走？

"文件 ▸ 备份图库…"会下载一个 zip，包含图库文件和全部原片，解压后原片可直接浏览，上限 4 GB。恢复则是反向操作：zip 读入新图库文件夹，逐条校验哈希，全部通过后才切换，旧数据原样保留在存储里。跨浏览器迁移、部署到新域名，靠这两个功能就够了。

性能与体积是什么水平？

完整模块原始约 13 MB，brotli 压缩后约 3 MB，比旧构建的 gzip 体积省 41%。这里有个容易忽略的取舍：体积优先的编译会让渲染慢 50%–130%，所以逐像素处理的核心 crate 保持最高优化级别，其余部分才按体积优化。结果是实测滑杆草稿渲染中位数约 4 ms。想量化自己机器的表现，加?bench参数打开页面，控制台会输出首帧、缩略图完成、滑杆延迟等指标。

上线到静态托管，配好三件事就行

发布包lightcraft-web-<版本>.zip是纯静态站点，上传到任意静态托管即可：

• MIME 类型：.wasm必须按application/wasm提供，否则浏览器拒绝流式编译
• 压缩：开启 gzip/brotli，下载量从 13 MB 压到 3–5 MB
• 缓存：文件名跨版本不变，用no-cache而不是immutable，避免升级后拿到旧模块

它也支持 iframe 嵌入，URL 参数?workers=N、?store=idb、?store=memory、?reset可灵活控制渲染线程与存储行为。

还有哪些没做到？

保持诚实：导出和自动调整目前仍在主线程运行，重载后第一条此类命令可能提示 "still loading"；写入耐久性是"下一帧落盘"，极端情况下崩溃会丢最后一条命令；控制通道 / MCP 自动化仅限桌面端（依赖 TCP 套接字）；预设文件的导入导出还没接入浏览器文件选择器。桌面端与网页端的完整差异对照，可以看 docs/web.md。

【免费下载链接】lightcraftLightCraft: An open-source non-destructive photo editor written by scratch in pure Rust项目地址: https://gitcode.com/gh_mirrors/li/lightcraft