浏览器里跑 1024 维向量检索，还能做到零云端成本、数据不出设备——这个组合放在两年前我会觉得是标题党，但用 TensorFlow.js 配合 Web Worker 实际跑通之后，我改主意了。整套方案的核心思路很直接：把视觉特征提取和向量相似度计算全部塞进浏览器，图片从用户本地读取、在内存里完成推理和检索，全程不经过任何服务器。适合谁参考？前端工程师、做端侧 AI 应用的开发者、对隐私敏感的产品团队，以及想在自己项目里加"以图搜图"能力但不想养 GPU 集群的人。下面我把这套东西从架构到代码到踩坑完整拆一遍。
1. 为什么把视觉检索放到端侧是笔划算的账
1.1 云端方案的真实成本结构
先算一笔账。假设你做一个以图搜图功能，用户上传一张图，服务端用 ResNet 或 CLIP 提取特征，再在向量库里做近邻搜索。看起来简单，但成本藏在三个地方。
第一是推理成本。一张图过一次特征提取模型，GPU 上大概几十毫秒，但你要为这个 GPU 实例持续付费。按某云厂商的 GPU 推理实例算，一张卡每小时几块到十几块不等，一天就是上百块。如果 QPS 不高，GPU 利用率可能只有百分之几，钱全浪费在空转上。
第二是向量存储和检索成本。1024 维的 float32 向量，一条就是 4KB。十万条就是 400MB，百万条就是 4GB。向量数据库要么自建要么用托管服务，托管服务按存储量和查询量计费，量一大账单就上来了。
第三是带宽和隐私合规成本。用户上传原图，图片要传到服务端，这本身消耗带宽。更麻烦的是隐私——用户的人脸、证件、私密照片传到你的服务器，你就得承担存储安全责任，出了泄露事件就是大事。合规审计、数据加密、访问日志，这些都是隐性成本。
1.2 端侧方案把这三笔账全部归零
端侧方案的本质是：把计算下放到用户的浏览器，用用户自己的 CPU/GPU 干活。你的服务器只负责发静态资源——HTML、JS、模型文件。模型文件可以放 CDN，一次加载之后浏览器缓存，后续几乎零请求。
成本结构变成这样：推理成本为零（用户设备承担），向量存储成本为零（存在用户本地 IndexedDB 或内存里），带宽成本只有首次加载模型的那几 MB。隐私方面，图片从头到尾没离开过用户的设备，你连图片长什么样都不知道，合规风险直接消失。
注意：端侧方案不是万能的。如果你的检索库有千万级向量，或者需要跨用户共享检索结果，端侧就不合适。它最适合的场景是"单用户本地库检索"——比如用户的个人相册去重、本地素材管理、设备端商品识别。
1.3 1024 维这个数字意味着什么
标题里特意提了 1024 维，这不是随便选的。视觉特征向量的维度直接决定检索精度和计算量。常见的维度有 512、768、1024、1280。1024 维通常是 CLIP 系列或一些 ViT 变体的输出维度，在精度和体积之间比较平衡。
维度越高，表达能力越强，但计算量按平方增长（余弦相似度是点积运算，复杂度 O(d)）。1024 维下，一次余弦相似度计算是 1024 次乘加。如果库里有 1 万条向量，一次全量检索就是 1000 万次乘加。这个量级在 JS 里跑，单线程会卡死主线程，所以必须上 Web Worker。这也是为什么标题把 TensorFlow.js 和 Web Worker 并列——前者负责推理，后者负责不阻塞 UI 的检索计算。
2. 整体架构：三个角色各司其职
2.1 主线程、Worker、模型三者的分工
这套系统里有三个关键角色，职责必须分清楚，否则很容易写出卡顿的代码。
主线程负责 UI 交互：文件选择、图片预览、结果展示、进度条更新。它绝对不能碰重计算，一旦主线程被占住，页面就卡死，用户以为崩了。
Web Worker 负责所有重计算：模型推理、特征提取、向量归一化、相似度计算、排序。它跑在独立线程，不阻塞 UI。Worker 和主线程之间通过 postMessage 通信，传的是结构化克隆的数据。
TensorFlow.js 模型是计算的核心。它可以在主线程加载，也可以在 Worker 里加载。我的建议是放在 Worker 里加载和推理，这样连模型初始化都不阻塞主线程。但要注意，模型文件较大时，Worker 里的加载时间会影响首次响应，需要做好加载状态提示。
2.2 数据流转的完整链路
一条完整的检索链路是这样的：
- 用户在主线程选择一张查询图片，主线程把图片转成 ImageBitmap 或 ArrayBuffer，postMessage 给 Worker。
- Worker 收到图片数据，用 TensorFlow.js 模型做预处理（缩放、归一化、转 tensor），然后推理得到 1024 维特征向量。
- Worker 对特征向量做 L2 归一化，这样后续余弦相似度就等价于点积，省一次开方。
- Worker 从 IndexedDB 或内存里取出候选向量库，逐条计算点积，得到相似度分数。
- Worker 对分数排序，取 Top-K，把结果（图片 ID + 分数）postMessage 回主线程。
- 主线程根据 ID 从本地存储取出对应图片，渲染结果列表。
整个链路里，图片数据只在主线程和 Worker 之间传递，没有网络请求。这就是"100% 隐私安全"的技术含义——不是靠承诺，是靠架构保证的。
2.3 为什么用 Web Worker 而不是 WebAssembly 或 WebGL
有人会问，既然要性能，为什么不上 WebAssembly 或者直接用 WebGL 做计算？
WebAssembly 确实快，但开发成本高，要把 C++/Rust 代码编译过来，调试也麻烦。对于向量检索这种逻辑不复杂的计算，JS 配合 TypedArray 已经够用。WebGL 适合大规模并行计算，但它的数据在 GPU 显存里，取回结果有开销，而且写 shader 做检索逻辑很别扭。
Web Worker 的优势是简单直接：它就是 JS，没有学习成本，能访问 IndexedDB、能加载 TensorFlow.js、能用 TypedArray。对于万级向量的检索，Worker 里的 JS 循环完全能在一秒内跑完。所以这个方案选 Worker 是性价比最高的。
3. 模型选型与 TensorFlow.js 加载策略
3.1 选哪个模型提取 1024 维特征
要得到 1024 维输出，可选的不多。我实测下来比较靠谱的有两类。
一类是 CLIP 的视觉编码器变体。CLIP ViT-B/32 的视觉输出是 512 维，ViT-L/14 是 768 维，要 1024 维得找特定版本或者做投影。有些社区转换的 CLIP 模型直接输出 1024 维，用起来方便。
另一类是一些轻量 ViT 或 MobileNet 的改造版。MobileNetV3 原版输出 1280 维，砍掉最后的分类头，取全局池化层输出，再经过一个线性层降到 1024 维，也能用。这种模型体积小，推理快，适合端侧。
选型时重点看三个指标：模型体积（影响首次加载）、推理延迟（影响体验）、检索精度（影响可用性）。我的经验是，端侧场景下模型体积控制在 20MB 以内比较合适，超过这个数首次加载会让用户等太久。
3.2 模型加载的两种方式与取舍
TensorFlow.js 加载模型有两种主流方式：从 URL 加载（tf.loadGraphModel或tf.loadLayersModel）和从 IndexedDB 加载。
从 URL 加载最简单，模型放 CDN，浏览器自动缓存。但缓存策略受 HTTP 头控制，用户清缓存后要重新下载。适合模型不大、更新不频繁的场景。
从 IndexedDB 加载需要先把模型存进去。TensorFlow.js 提供了model.save('indexeddb://my-model')和tf.loadLayersModel('indexeddb://my-model')。这种方式的好处是模型持久化在本地，不受 HTTP 缓存影响，加载速度稳定。缺点是首次还是要从网络下载再存进去。
我的做法是混合：首次从 URL 加载，加载完立刻存一份到 IndexedDB，后续优先从 IndexedDB 读。这样兼顾首次体验和后续稳定性。
async function loadModelWithCache() { const modelKey = 'indexeddb://vision-encoder-1024'; try { // 优先从 IndexedDB 加载 const model = await tf.loadGraphModel(modelKey); console.log('模型从 IndexedDB 加载成功'); return model; } catch (e) { // 本地没有，从 URL 加载 console.log('IndexedDB 无缓存，从网络加载'); const model = await tf.loadGraphModel('/models/vision-encoder-1024/model.json'); // 存一份到 IndexedDB await model.save(modelKey); return model; } }3.3 在 Worker 里加载模型的注意事项
把模型加载放进 Worker 有个坑：Worker 里没有 DOM，不能用document或window。TensorFlow.js 在 Worker 里跑需要确保用的是纯计算后端，不能依赖 WebGL 的 DOM 上下文。
实测下来，Worker 里用 WebGL 后端有时会失败，因为 OffscreenCanvas 的支持情况因浏览器而异。稳妥的做法是在 Worker 里用 CPU 后端（tf.setBackend('cpu')），或者用 WASM 后端（tf.setBackend('wasm')）。WASM 后端在 Worker 里表现不错，速度比纯 CPU 快不少。
// 在 Worker 脚本开头 importScripts('https://cdn.jsdelivr.net/npm/@tensorflow/tfjs'); importScripts('https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-backend-wasm'); // 设置 WASM 后端 tf.setBackend('wasm').then(() => { console.log('WASM 后端就绪'); });提示：WASM 后端需要加载对应的 .wasm 文件，路径要配对。如果路径不对，会静默回退到 CPU，速度慢很多。建议在初始化后打印
tf.getBackend()确认。
4. 特征提取的预处理细节决定检索成败
4.1 图片预处理的标准化流程
模型推理前的预处理，直接决定特征质量。不同模型的预处理要求不一样，但通用流程是：解码图片 → 缩放到模型输入尺寸 → 像素值归一化 → 转成 tensor → 增加 batch 维度。
以常见的 224x224 输入为例，缩放时要注意保持宽高比还是直接拉伸。CLIP 系列通常是中心裁剪加缩放，MobileNet 系列多是直接 resize。这个细节如果搞错，特征会偏移，检索精度下降。
function preprocessImage(imageBitmap, targetSize = 224) { return tf.tidy(() => { // 转成 tensor let tensor = tf.browser.fromPixels(imageBitmap); // 缩放到目标尺寸 tensor = tf.image.resizeBilinear(tensor, [targetSize, targetSize]); // 归一化到 [0, 1] 或 [-1, 1]，看模型要求 tensor = tensor.toFloat().div(255.0); // 增加 batch 维度 [1, 224, 224, 3] tensor = tensor.expandDims(0); return tensor; }); }tf.tidy()很重要，它会自动清理中间 tensor，防止内存泄漏。在 Worker 里长时间跑推理，不清理内存很快就会爆。
4.2 归一化方式选错会导致检索全乱
归一化有两种常见方式：除以 255 得到 [0,1]，或者减均值除标准差得到 [-1,1]。用错的话，特征分布会偏，相似度计算就失去意义。
判断方法很简单：看模型文档或者看模型转换时的配置。如果拿不准，可以两种都试，用同一张图跑两次，看哪种的特征向量在同类图片上更聚集。我踩过这个坑，一开始用 [0,1] 归一化跑一个要求 [-1,1] 的模型，检索结果完全是乱的，排查了半天才发现是归一化的问题。
4.3 特征向量的 L2 归一化不能省
拿到 1024 维原始特征后，一定要做 L2 归一化。归一化之后，向量的模长变成 1，两个向量的余弦相似度就等于它们的点积。这样检索时只需要算点积，省掉计算模长和开方的步骤，速度快很多。
function l2Normalize(vector) { const norm = Math.sqrt(vector.reduce((sum, v) => sum + v * v, 0)); return vector.map(v => v / (norm + 1e-8)); }加1e-8是防止除零。这个细节在向量全零时能救命，虽然正常情况不会出现全零向量，但防御性编程没坏处。
5. Web Worker 里的向量检索实现
5.1 暴力检索 vs 近似检索的选择
向量检索分两大类：暴力检索（Brute-force）和近似最近邻（ANN）。暴力检索就是拿查询向量和库里每一条算相似度，全量比较，结果精确但慢。ANN 用索引结构加速，快但可能漏掉真正的最近邻。
端侧场景下，我的建议是：库小于 5 万条时用暴力检索，简单可靠，结果精确。超过 5 万条再考虑 ANN，比如 HNSW 的 JS 实现。因为端侧库通常不会太大，暴力检索的延迟可以接受。
暴力检索的复杂度是 O(N*d)，N 是库大小，d 是维度。1024 维、1 万条，就是 1000 万次乘加。在 Worker 里用 TypedArray 优化，大概几百毫秒能跑完。这个延迟用户能接受。
5.2 用 Float32Array 优化内存和速度
JS 普通数组存浮点数，每个元素都是对象，内存开销大，访问也慢。用Float32Array存向量，内存连续，访问快，而且和 TensorFlow.js 的 tensor 数据格式兼容。
// 假设 vectors 是 Float32Array，长度是 N * 1024 function bruteForceSearch(queryVec, vectors, dim, topK) { const N = vectors.length / dim; const scores = new Float32Array(N); for (let i = 0; i < N; i++) { let dot = 0; const offset = i * dim; for (let j = 0; j < dim; j++) { dot += queryVec[j] * vectors[offset + j]; } scores[i] = dot; } // 取 Top-K const indices = Array.from(scores.keys()); indices.sort((a, b) => scores[b] - scores[a]); return indices.slice(0, topK).map(idx => ({ index: idx, score: scores[idx] })); }这个循环是性能关键。内层循环用局部变量缓存queryVec[j]和vectors[offset + j]，减少数组访问次数。实测下来，这样写比用普通数组快三到五倍。
5.3 Top-K 选择的优化技巧
上面的代码用sort取 Top-K，当 N 很大时排序开销不小。N 是 1 万时，排序大概几十毫秒，可以接受。但如果 N 到 10 万，排序就成瓶颈了。
优化方法是维护一个大小为 K 的最小堆，遍历一遍就能得到 Top-K，复杂度从 O(N log N) 降到 O(N log K)。K 通常很小（比如 10），所以提升明显。不过堆的实现代码复杂一些，库不大时没必要上。
还有一个技巧是提前终止：如果只需要分数超过某个阈值的项，可以在遍历时跳过明显不相关的。但这需要向量有某种结构，通用场景用不上。
5.4 Worker 与主线程的通信协议设计
Worker 和主线程通信，消息格式要设计好，否则容易乱。我习惯用type字段区分消息类型，payload放数据。
// 主线程发消息 worker.postMessage({ type: 'SEARCH', payload: { imageBitmap: bitmap, topK: 10 } }); // Worker 回消息 self.postMessage({ type: 'SEARCH_RESULT', payload: { results: [{ index: 3, score: 0.92 }, ...], elapsed: 234 } });传 ImageBitmap 比传 ArrayBuffer 高效，因为 ImageBitmap 是可直接用于渲染的格式，不需要重新解码。但要注意 ImageBitmap 是 transferable 对象，postMessage 时可以转移所有权，避免拷贝。
worker.postMessage({ type: 'SEARCH', payload: { imageBitmap: bitmap } }, [bitmap]);第二个参数是 transfer 列表，把 bitmap 的所有权转给 Worker，主线程就不能再用了。这样零拷贝，速度快。
6. 向量库的本地持久化方案
6.1 IndexedDB 存向量的正确姿势
向量库要持久化，否则每次刷新页面都要重新提取所有图片的特征，太慢。IndexedDB 是浏览器里唯一能存大量结构化数据的地方。
存向量时，Float32Array可以直接存，IndexedDB 支持 ArrayBuffer 和 TypedArray。但要注意，存进去和取出来的类型要一致，否则会出错。
async function saveVectors(db, vectors, metadata) { const tx = db.transaction('vectors', 'readwrite'); const store = tx.objectStore('vectors'); await store.put({ id: 'main', data: vectors.buffer, // 存 ArrayBuffer dim: 1024, count: vectors.length / 1024, metadata: metadata }); await tx.done; }存vectors.buffer而不是vectors本身，取出来时再包一层new Float32Array(buffer)。这样兼容性最好。
6.2 增量更新与全量重建的权衡
用户不断添加新图片，向量库要更新。有两种策略：增量追加和全量重建。
增量追加是把新向量拼到现有数组后面。问题是Float32Array长度固定，追加要新建数组再拷贝，频繁操作开销大。可以预留空间，比如每次扩容 1.5 倍，减少拷贝次数。
全量重建是每次重新提取所有图片的特征。简单但慢，图片多时不可接受。
我的做法是：内存里维护一个可增长的普通数组存向量，定期（比如每添加 100 张）批量写入 IndexedDB。这样兼顾性能和持久化。
6.3 图片数据与向量的关联存储
向量检索返回的是索引，要显示图片还得能找到对应的图片数据。所以向量库要存图片的引用。
如果图片本身也存 IndexedDB，可以存图片的 Blob 和向量的对应关系。如果图片是用户本地文件，可以存文件路径或 File 对象的引用（但 File 对象不能持久化，只能存路径）。
// 元数据结构 { id: 'img_001', vectorOffset: 0, // 在向量数组中的偏移 thumbnail: blob, // 缩略图 Blob name: 'photo.jpg', addedAt: 1699999999999 }存缩略图而不是原图，能大幅节省空间。检索结果展示缩略图就够了，用户点开再看原图。
7. 实测中遇到的坑与排查过程
7.1 Service Worker 注册报错 InvalidStateError 的真相
热词里有个"加载 web 视图时出错: error: could not register service worker: invalidstatee"，这个我踩过。报错信息里的invalidstatee其实是InvalidStateError被截断了。
这个错误的常见原因是：在 Service Worker 已经注册或正在注册时，重复调用register，或者在不支持 Service Worker 的环境（比如某些 WebView、隐私模式）里调用。
排查步骤是这样的：先确认navigator.serviceWorker是否存在，不存在说明环境不支持。然后检查是否重复注册，用getRegistration先查再注册。
if ('serviceWorker' in navigator) { const existing = await navigator.serviceWorker.getRegistration(); if (!existing) { try { await navigator.serviceWorker.register('/sw.js'); } catch (e) { console.warn('SW 注册失败，不影响主功能', e); } } }关键认知是：Service Worker 不是这套方案的必需品。它只用来做资源缓存加速，注册失败不影响向量检索功能。所以要用 try-catch 包住，失败就降级，别让它阻断主流程。
7.2 Worker 里 TensorFlow.js 后端初始化失败
在 Worker 里初始化 TensorFlow.js 时，遇到过Backend not found或者后端初始化超时。原因是 Worker 里没有 DOM，某些后端依赖 DOM 环境。
解决办法是显式指定后端，并且等待后端就绪再跑推理。
await tf.setBackend('wasm'); await tf.ready(); // 等待后端完全就绪tf.ready()这行不能省。不等待就调推理，会报后端未就绪。我一开始漏了这行，间歇性失败，加了之后就稳了。
7.3 大图片导致内存暴涨的处理
用户选了一张 8000x6000 的大图，直接fromPixels会创建巨大的 tensor，内存瞬间飙升，Worker 可能被浏览器杀掉。
处理方法是先缩小再处理。用createImageBitmap时指定 resize 参数，或者用 canvas 先缩小。
const bitmap = await createImageBitmap(file, { resizeWidth: 1024, resizeHeight: 1024, resizeQuality: 'medium' });这样解码时就缩小了，内存占用可控。注意resizeWidth和resizeHeight同时指定会拉伸，只指定一个会保持宽高比。视觉特征提取对轻微形变不敏感，直接拉伸到正方形也可以接受。
7.4 检索结果不稳定的排查链路
有段时间检索结果时好时坏，同一张图两次检索结果不一样。排查过程是这样的：
先怀疑是随机性，检查模型有没有 dropout 之类的随机层。推理时应该是确定的，排除了这个。
再检查预处理，发现图片缩放用的插值算法在不同调用路径下不一致，有时用 bilinear 有时用 nearest。统一成 bilinear 后，结果稳定了。
最后发现归一化那里有个浮点误差累积，1e-8的 epsilon 在某些极端向量上不够。改成1e-6后彻底稳定。
这个排查链路说明：端侧 AI 的不稳定，往往不是模型问题，而是预处理和数据管道的细节问题。每一步都要可复现、可验证。
8. 性能优化的几个实战手段
8.1 批量推理提升吞吐
如果一次要处理多张图片（比如用户批量导入），逐张推理效率低。TensorFlow.js 支持 batch 推理，把多张图拼成一个 batch tensor，一次前向传播搞定。
function batchPreprocess(bitmaps, targetSize = 224) { return tf.tidy(() => { const tensors = bitmaps.map(bmp => { let t = tf.browser.fromPixels(bmp); t = tf.image.resizeBilinear(t, [targetSize, targetSize]); return t.toFloat().div(255.0); }); return tf.stack(tensors); // [B, 224, 224, 3] }); }batch size 别太大，4 到 8 比较合适。太大内存吃不消，太小提升不明显。
8.2 向量检索的分块计算
库很大时，一次性遍历所有向量可能让 Worker 长时间占用。可以分块计算，每块算完 postMessage 一次进度，让主线程更新进度条。
const CHUNK_SIZE = 1000; for (let start = 0; start < N; start += CHUNK_SIZE) { const end = Math.min(start + CHUNK_SIZE, N); // 计算这一块 // ... self.postMessage({ type: 'PROGRESS', payload: { done: end, total: N } }); }这样用户能看到进度，不会以为卡死了。分块还有个好处是可以在块之间让出执行权，虽然 Worker 里没必要，但逻辑上更清晰。
8.3 缓存查询特征避免重复计算
如果用户反复检索同一张图，没必要每次重新提取特征。可以在 Worker 里用一个 Map 缓存图片的 hash 到特征的映射。
const featureCache = new Map(); async function getFeature(imageBitmap, imageHash) { if (featureCache.has(imageHash)) { return featureCache.get(imageHash); } const feature = await extractFeature(imageBitmap); featureCache.set(imageHash, feature); return feature; }hash 可以用图片的尺寸加文件大小加修改时间生成，简单够用。缓存要设上限，比如最多 100 条，超了就清最旧的，防止内存无限增长。
9. 隐私安全的架构级保证
9.1 数据不出设备的技术验证
"100% 隐私安全"不是靠嘴说的，要能验证。验证方法是打开浏览器开发者工具的 Network 面板，操作一遍完整流程，看有没有图片数据外发。
正常情况下，除了首次加载模型和静态资源，不应该有任何包含图片数据的请求。如果看到有请求带着图片内容，说明架构有问题。
还可以用PerformanceObserver监控资源加载，确认没有意外的网络请求。
const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.initiatorType === 'fetch' || entry.initiatorType === 'xmlhttprequest') { console.log('网络请求:', entry.name); } } }); observer.observe({ entryTypes: ['resource'] });9.2 模型文件本身不包含用户数据
有人担心模型文件会不会偷偷上传数据。模型文件是静态的权重，不包含任何用户数据。它从 CDN 加载，加载过程是单向的——浏览器下载模型，不上传任何东西。
要确保的是模型来源可信。用官方或知名社区转换的模型，别用来路不明的模型文件。模型文件可以用 SRI（子资源完整性）校验，防止被篡改。
<script src="https://cdn.example.com/tf.min.js" integrity="sha384-xxxxx" crossorigin="anonymous"></script>9.3 本地存储的加密考量
向量和缩略图存在 IndexedDB 里，默认是不加密的。如果设备被他人物理访问，数据可能被读取。对隐私要求极高的场景，可以在存入前加密。
但加密会带来性能开销，而且密钥管理本身是个难题——密钥存哪里？如果存 localStorage，一样能被读。所以端侧加密的边际收益有限，除非配合用户密码派生密钥。
我的建议是：普通场景不加密，靠设备本身的锁屏和浏览器沙箱保护。高敏感场景，让用户设置一个密码，用 PBKDF2 从密码派生密钥，加密向量库。这样即使设备被访问，没有密码也读不出数据。
10. 端侧 AI 硬件部署的延伸思考
10.1 浏览器之外的端侧形态
浏览器方案的好处是跨平台、零安装。但端侧 AI 不只有浏览器一种形态。原生 App、桌面应用、甚至嵌入式设备，都是端侧的载体。
原生 App 可以用 TensorFlow Lite 或 ONNX Runtime，性能比浏览器好，能访问更多硬件加速。桌面应用可以用 Electron 打包浏览器方案，或者用原生框架。
选择哪种形态，取决于分发渠道和性能要求。浏览器方案适合快速验证和轻量场景，原生方案适合对性能有极致要求的场景。
10.2 端侧硬件的算力现状
现在的端侧硬件算力比几年前强太多。手机上的 NPU 每秒能跑几万亿次运算，跑个视觉特征提取绰绰有余。浏览器通过 WebGPU 也能访问 GPU 算力，虽然支持度还在完善中。
WebGPU 是未来的方向。它比 WebGL 更现代，计算能力更强，TensorFlow.js 已经在适配。等 WebGPU 普及，浏览器里的推理速度会再上一个台阶。
10.3 端侧与云端的混合架构
纯端侧不是唯一选择。混合架构可能更实用：端侧做初步筛选和隐私敏感的处理，云端做重计算和跨用户检索。
比如，端侧提取特征后，只上传特征向量（不上传原图），云端做大规模检索。这样既保护了原图隐私，又利用了云端算力。特征向量本身也可能泄露信息，但比原图安全得多。
架构选择没有标准答案，要看具体场景的隐私要求、性能要求和成本预算。端侧方案的价值在于，它提供了一个隐私和成本都极优的选项，让很多以前必须上云的场景可以在本地解决。
我在实际项目里用这套方案做过一个本地相册去重工具，几千张照片的库，检索延迟稳定在几百毫秒，内存占用控制在 200MB 以内，全程无网络请求。踩过的坑主要集中在预处理一致性和 Worker 后端初始化上，这两块搞定之后，整体非常稳。如果你也在做类似的东西，建议先把预处理管道固定下来，用几张已知相似的图做基准测试，确认特征质量没问题，再往上堆功能。
