FAQ

FAQ

浏览器请求一定会返回压缩 JS 吗？ / Will browsers always receive compressed JS?

不一定。必须满足：

• 请求头包含 Accept-Encoding，例如 br,zstd,gzip。
• 对应压缩变体存在，或者 lazy/warmup 已生成。
• asset 是可压缩 media type，且大小超过 compression.min_size。
• compression.enable=true 且 mode 不是 off，或者存在 source sidecar。

Not always. Conditions:

• The request must include Accept-Encoding, for example br,zstd,gzip.
• The matching variant must exist, or lazy/warmup generation must have completed.
• The asset must be compressible and larger than compression.min_size.
• compression.enable=true and mode is not off, or a source sidecar exists.

Accept: */* 不控制压缩。压缩由 Accept-Encoding 控制。

Accept: */* does not negotiate compression. Compression is negotiated by Accept-Encoding.

Vite 插件生成的 .br / .gz / .zst 会被识别吗？

会，只要原始文件也存在。例如：

Yes, as long as the original file exists. Example:

assets/app.abc123.js
assets/app.abc123.js.br
assets/app.abc123.js.gz
assets/app.abc123.js.zst

这些 sidecar 会被注册为 source variants，不需要 SPACK 再生成一次。

These sidecars are registered as source variants, so SPACK does not need to generate them again.

robots.txt 谁优先？

默认静态文件优先：

Static files win by default:

• source root 中存在 robots.txt 且 robots.override=false: 返回静态文件。

• 不存在静态文件且 robots.enable=true: 使用 embed template 生成。

• robots.override=true: 使用配置生成。

• If source root has robots.txt and robots.override=false: serve the static file.

• If no static file exists and robots.enable=true: render from embedded template.

• If robots.override=true: render from config.

为什么不把内部定时任务暴露到配置？

source rescan、artifact janitor 和 cache warmer 是 SPACK 的内部运行时机制。把它们暴露给用户会让部署者误以为必须理解和调参这些任务。当前策略是内部写死合理默认值，并通过 metrics 暴露运行状态。

Source rescan, artifact janitor, and cache warmer are internal runtime mechanisms. Exposing them as user config would force deployers to reason about internals. SPACK keeps reasonable internal defaults and exposes their behavior through metrics.

SPACK 可以替代 Nginx 吗？

取决于场景。

It depends.

适合：

• 单个前端构建产物 runtime。
• SPA fallback。
• 压缩和图片变体内建。
• 需要 Prometheus/Grafana/runtime metadata。
• 容器镜像内静态资源分发。

Good fit:

• Single frontend build output runtime.
• SPA fallback.
• Built-in compression and image variants.
• Prometheus/Grafana/runtime metadata.
• Static asset delivery inside container images.

不适合：

• 反向代理。
• TLS termination。
• 多 location 复杂 rewrite。
• 通用文件服务器。
• 动态脚本插件。

Not a good fit:

• Reverse proxy.
• TLS termination.
• Complex multi-location rewrite rules.
• General-purpose file server.
• Dynamic scripting plugins.

为什么有 prepared snapshot 和 resolver 两套概念？

prepared snapshot 是生产热路径的预编译响应模型。resolver 保留动态解析能力，主要服务测试、fallback、variant generation decisions 和一些非热路径决策。长期方向是让热路径尽量走 prepared snapshot。

The prepared snapshot is the precompiled response model for production hot paths. The resolver keeps dynamic resolution capability for tests, fallback, variant generation decisions, and non-hot-path logic. The long-term direction is to move hot paths into prepared snapshots.

prefork 一定更快吗？

不一定。prefork 对 CPU-heavy 或多核场景可能有优势，但对本地 Docker、文件 IO、cache 命中、容器 CPU 分配等因素敏感。SPACK 提供 task perf:k6:frontend 和 task perf:k6:split 来直接比较 non-prefork、prefork 和 Nginx。

Not always. Prefork can help CPU-heavy or multi-core workloads, but local Docker, file IO, cache hits, and container CPU allocation matter. SPACK provides task perf:k6:frontend and task perf:k6:split to compare non-prefork, prefork, and Nginx directly.

应该用 lazy 还是 warmup？

推荐默认 lazy。

Default recommendation: lazy.

• lazy: 启动快，首次请求可能返回 identity，后续命中生成变体。

• warmup: 启动成本更高，但首个用户请求更可能直接命中压缩/图片变体。

• lazy: faster startup; first request may return identity; later requests hit generated variants.

• warmup: higher startup cost; first user request is more likely to hit compression/image variants.

生产环境要开启 debug runtime 吗？

可以开启，但不要暴露公网。/prometheus、pprof、statsviz 应放在可信网络或内部 scrape path。

You can enable it, but do not expose it publicly. /prometheus, pprof, and statsviz should stay on trusted networks or internal scrape paths.