上线前的 5 道关卡FilePizza 从 P2P 文件传输 Demo 到生产可用的完整升级指南【免费下载链接】filepizza:pizza: Peer-to-peer file transfers in your browser项目地址: https://gitcode.com/GitHub_Trending/fi/filepizzaFilePizza 是一个基于 Next.js WebRTC 的浏览器端 P2P 文件传输工具文件从上传者浏览器直连到下载者不经过任何服务器多文件自动打包成 zip 流式下载。它的教程路径非常顺滑但本机跑通和敢上线之间还隔着五道风险关卡构建、凭据与配置、运行时行为、数据与权限、体验一致性。本文按这五个阶段逐项排查每一条都落到具体文件和配置项。功能速览WebRTC 直连通道与 PeerJS 信令上传/下载逻辑在src/components/Uploader.tsx、src/components/Downloader.tsx频道生命周期在src/channel.ts分享链接生成8 位短 slug 与 4 词长 slug随机数生成在src/slugs.ts词表在src/toppings.ts流式下载public/sw.jsService Worker StreamSaver多文件 zip 打包在src/zip-stream.ts与src/utils/download.ts服务端状态频道元数据存 Redis未配置时降级内存连接在src/redisClient.tsNAT 穿透coturn 集成临时凭据生成在src/coturn.ts与src/app/api/ice/route.ts部署Dockerfile多阶段构建 docker-compose.yml/docker-compose.production.yml一键更新脚本scripts/pull-and-run.sh快速启动git clone https://gitcode.com/GitHub_Trending/fi/filepizza cd filepizza pnpm install pnpm dev环境要求Node LTSDockerfile 使用node:lts-alpine加 pnpm需要完整功能Redis coturn时直接用pnpm dev:full。阶段一构建期 —— standalone 产物完整性与 Node 版本锁定构建脚本在偷偷复制 public 和 .next/staticpackage.json的build脚本不是裸next buildbuild: next build cp -r public .next/standalone/ cp -r .next/static .next/standalone/.next/next.config.js 里output: standalone只产出最小运行时静态资源必须手工补进产物而public里恰好有流式下载依赖的sw.js和stream.html。如果你照 Next.js 官方文档把构建简化成裸next build生产环境的 Service Worker 会消失大文件流式下载静默降级成内存 blob。Dockerfile 单独COPY了public和.next/static说明这条链路是显式契约不是可选项。验证动作本地跑一次pnpm build确认.next/standalone/下存在sw.js、stream.html和.next/static。生产化改造方向把这两条 cp 纳入 CI 的产物完整性断言缺文件直接构建失败。没有 engines 声明frozen-lockfile 会卡住镜像构建package.json没有engines字段Node 版本靠口头约定而 Docker 构建用的是pnpm install --frozen-lockfileDockerfile。本机升了依赖却不提交锁文件镜像构建直接以锁文件不一致报错反过来用太旧的 Node本地可能侥幸跑通、容器里直接崩。误区 vs 正确姿势误区是锁文件只影响安装速度正确姿势是把pnpm-lock.yaml当作部署产物的一部分依赖变更必须与锁文件同一次提交并在package.json补上engines。验证动作docker compose build在干净环境复现一次确认镜像构建全绿。阶段二凭据与配置 —— 环境变量是唯一的真相源config.ts 里的 redisURL 是个误导项src/config.ts 里写着redisURL: redis://localhost:6379/0看似就是 Redis 地址——但全仓库没有任何代码读这个字段。真实连接在 src/redisClient.tsredisClient process.env.REDIS_URL ? new Redis(process.env.REDIS_URL) : new Redis() // 未配置时 fallback 到 localhost:6379只改config.ts而不设REDIS_URL环境变量生产环境仍然会连 127.0.0.1:6379容器里没有 Redis频道相关接口全部报错。为什么会出现这种设计src/channel.ts 的getOrCreateChannelRepo同样以process.env.REDIS_URL是否存在来选 Redis 或内存存储——环境变量是双重真相源config.ts里的redisURL是没人清的死代码。验证动作启动后看日志出现[ChannelRepo] Using Redis storage才算生效看到in-memory说明环境变量没配上。生产化改造方向删掉死字段或让它读环境变量做默认值全项目只留一个配置来源。浮动版本latest 标签就是隐式升级docker-compose.yml 与 docker-compose.production.yml 都是redis:latest应用镜像是kern/filepizza:latest而 scripts/pull-and-run.sh 直接docker pull kern/filepizza:latest后up -d。上游 Redis 某次发大版本、或镜像构建出一版坏改动你的更新脚本会把它原样推进生产。误区 vs 正确姿势误区是latest 总能拿到最新修复正确姿势是生产 compose 固定具体版本号或 digest升级变成显式动作并留回滚点。TURN_REALM 默认值是别人的域名PeerJS 自建脚本缺文件src/coturn.ts 写凭据时用process.env.TURN_REALM || file.pizza当 realm。你自建了 coturn 却不设TURN_REALM凭据会挂到file.pizza这个 realm 下——功能能跑但日后审计和排障完全对不上号。同理src/app/api/ice/route.ts 的PEERJS_HOST默认指向公共云0.peerjs.com意味着所有信令都走第三方。还有一个隐蔽的坑package.json的start:peerjs脚本指向./bin/peerjs.js该文件在本仓库中不存在本仓库未提供需自行部署自建 PeerJS 服务。自托管 PeerJS 时别指望这个脚本兜底。验证动作设好COTURN_ENABLEDtrue后请求/api/ice检查响应iceServers里是否出现turn:地址和非空username。阶段三运行时行为 —— 开发模式的看起来正常不算数reactStrictMode:false 关掉的是一把双刃剑next.config.js 注释写得很直白上传和下载组件在useEffect里监听 peerjs 事件开发模式双调用会把连接建两次所以 Strict Mode 被整体关掉。生产构建本来就不双调用这个配置对线上无感——真正的风险是这个 effect 本身不幂等谁要是清理配置把 Strict Mode 重新打开开发环境立刻出现重复 peer 连接的诡异现象而根因是 effect 没有做已创建则跳过的保护。生产化改造方向给 peer 创建加幂等守卫已存在则直接返回而不是依赖配置项压制现象。Service Worker 下载链接不可重试public/sw.js给每次下载生成带Math.random()的 URL 存进Map在onfetch里拦截并返回流响应前执行map.delete(url)。后果是下载链接一次性的刷新或重发请求就没了SW 未注册成功或浏览器不支持 SW 时流式下载整条链路不可用StreamSaver 只能回退。为什么 URL 里要掺随机数避免缓存命中和并发串流。对下载一次就走的场景没问题但如果产品要做断点重下就得在应用层保留会话并允许重新发起。验证动作下载完成后打开 DevTools → Application → Service Workers确认/sw.js处于 activating/activated 状态并留意回退路径的日志。COTURN_ENABLEDtrue 但 Redis 不可用ICE 接口直接 500src/app/api/ice/route.ts 在COTURN_ENABLED打开时调用setTurnCredentials写 RedisRedis 连不上就抛错、接口 500所有端拿不到 TURN 地址而COTURN_ENABLED未设置时又只返回 STUN。配置开关、Redis 可用性、coturn 三者构成三角依赖缺任何一角都是静默降级。生产化改造方向ice 路由在写 Redis 失败时降级返回 STUN-only 配置并记告警别把 500 暴露给所有 peer。阶段四数据与权限 —— 这一节决定你能不能睡好觉仅凭 slug 就能销毁频道等于送了把 DoS 工具src/app/api/destroy/route.ts 的注释说明了动机让举报违规的人能销毁频道。但实现是const { slug } await request.json() // 只校验 slug 存在没有 secret // ... await getOrCreateChannelRepo().destroyChannel(slug)对照 src/channel.ts 的renewChannel续期必须secret匹配destroyChannel却不验。任何拿到分享链接的人8 位短 slug 尤其容易被随手转发都能直接掐断你的传输而且没有任何频率限制攻击成本约等于零。生产化改造方向destroy 增加独立密钥或绑定举报流程的校验并在网关层按 IP 限频。开发版 compose 把 Redis 暴露到所有网卡docker-compose.yml 把 6379 映射成6379:6379绑定所有网卡Redis 实例也没有密码redis: image: redis:latest ports: - 6379:6379 # 绑定 0.0.0.0且无认证Redis 里存着频道 secret含上传密码和 TURN 凭据。拿开发版 compose 直接部署到公网 VPS等于把这些数据裸奔。docker-compose.production.yml 绑定到127.0.0.1:6379这才是正确姿势。验证动作启动后用ss -ltnp查宿主机确认 6379 只监听 127.0.0.1有条件的话再从外部网络nc一次确认不可达。API 无速率限制输入校验助手没接上src/routes.ts提供了getBodyKey助手按 src/config.ts 的bodyKeysmin 3 / max 256做长度校验——但src/app/api/下四个路由处理函数都没用它只校验字段存在。/api/create每次请求建一个频道/api/ice每次生成一条 24 小时有效期的 TURN 凭据src/app/api/ice/route.ts 里ttl 86400/api/renew还能无限续期。没有频率限制时脚本可以无限灌 Redis。生产化改造方向反向代理层按 IP 做令牌桶限频同时把routes.ts的校验真正接回路由。阶段五体验一致性 —— 静态资源路径与 TTL 预期流式下载绑死同源 /stream.htmlsrc/utils/download.ts 把streamSaver.mitm设为window.location.host /stream.htmlSW 也假设从同源根路径注册。生产环境若部署在子路径如example.com/pizza/或通过 CDN 把静态资源放到别的源MITM 页面直接 404流式下载整体失效大文件改走内存占用翻倍。验证动作直接访问你线上域名的/stream.html和/sw.js两者都必须 200 且内容正确。一小时 TTL 是写进用户体验的承诺src/config.ts 里channel.ttl为一小时。上传者关闭浏览器后频道仍留在 Redis但已无人可发数据下载者对着死链干等到超时续期/api/renew依赖上传者页面持续存活。生产化改造方向页面上展示剩余有效期、提醒上传者保持页面开启或按传输进度动态续期。上线前检查表以上风险项压缩成一张可顺序执行的表阶段检查动作涉及文件/配置严重度构建standalone 产物含 sw.js / stream.html / staticpackage.json build 脚本、next.config.js构建补 engines、锁文件随依赖同提交docker build 复现package.json、Dockerfile凭据REDIS_URL 已设且日志出现 Using Redis storagesrc/redisClient.ts、src/config.ts凭据固定 Redis 与应用镜像版本弃用 latestdocker-compose*.yml、scripts/pull-and-run.sh凭据自设 TURN_REALM确认 PEERJS 信令归属start:peerjs 文件缺失需自建src/coturn.ts、src/app/api/ice/route.ts运行时peer 创建幂等化不依赖 reactStrictMode:false 压制next.config.js、Uploader/Downloader运行时SW 注册状态与下载回退路径演练public/sw.js、src/utils/download.ts运行时Redis 故障时 ICE 接口降级而非 500src/app/api/ice/route.ts数据destroy 增加 secret 校验或限频src/app/api/destroy/route.ts数据Redis 只绑 127.0.0.1 并加密码禁用 dev compose 上生产docker-compose.yml数据create / renew / ice 全局限频接上 routes.ts 校验src/app/api/*、src/routes.ts体验线上域名 /stream.html、/sw.js 均 200src/utils/download.ts体验TTL 可见性上传提示src/config.ts、src/channel.ts教程友好意味着开箱即跑不等于可以上线FilePizza 的构建链路、配置误导项和权限缺口全都藏在顺滑的演示体验背后。而你在逐项排查中沉淀下来的三件事——验证构建产物完整性、把配置收敛到单一真相源、给每个状态变更接口补上鉴权与限频——是任何自建 Web 服务通用的生产升级方法论。对照上表清掉所有 项再把你的 P2P 文件传输推向生产吧 【免费下载链接】filepizza:pizza: Peer-to-peer file transfers in your browser项目地址: https://gitcode.com/GitHub_Trending/fi/filepizza创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考