免费部署机器学习Web应用的四条实战路径

1. 这不是“免费托管”，而是用对工具链把模型服务跑起来的实战路径

“Deploy Machine Learning Web Apps for Free”这个标题，乍看像一句营销口号，但在我过去三年帮27个团队落地AI应用的过程中，它其实是一条被反复验证、踩过坑也填过坑的实操路径。核心关键词—— machine learning web app 、 free deployment 、 model serving ——指向的从来不是“零成本魔法”，而是：如何在不依赖付费云服务（如AWS SageMaker Realtime Endpoint、Azure ML Studio Hosting、GCP Vertex AI Predictions）的前提下，把训练好的模型（PyTorch、TensorFlow、scikit-learn、甚至ONNX格式）封装成可被网页调用的API，并让一个真实用户能打开浏览器、上传图片/输入文本、点击提交、3秒内看到预测结果。它适合三类人：刚完成课程项目想展示成果的学生、初创团队MVP阶段验证需求的产品经理、以及不想为每月$49的Heroku Hobby dyno或$25的Render Web Service买单的独立开发者。关键在于“Free”二字的边界——它指代的是 基础设施层零月租 （即不产生持续性计算资源费用），而非完全零投入；你仍需花时间做模型轻量化、接口封装、前端联调和错误兜底，这些是无法被“免费”替代的隐性成本。我见过太多人卡在“部署”这个词上：以为部署=上传模型文件到某平台点一下按钮，结果发现模型加载失败、API返回500、并发一高就超时、或者根本不知道怎么把Flask后端和React前端连通。这篇文章不讲理论，只讲我在GitHub Actions自动构建、Hugging Face Spaces真机压测、Streamlit Cloud一键发布、以及Cloudflare Workers无服务器推理这四条路径中，每一步敲什么命令、改哪行代码、为什么这么选、以及哪类模型该走哪条路——全部基于真实项目日志和监控截图还原。

2. 四条免费部署路径的底层逻辑与适用场景拆解

选择哪条免费部署路径，本质是在 模型复杂度、响应延迟容忍度、前端交互自由度、以及维护成本 之间做取舍。没有银弹，只有匹配。下面这四条路，我按“从最省心到最可控”的顺序排列，每条都附带真实项目案例的决策树。

2.1 Hugging Face Spaces：最适合快速验证模型能力，但交互受限

Hugging Face Spaces 是目前对机器学习开发者最友好的免费部署平台。它本质是一个预配置的Docker环境，内置Gradio或Streamlit运行时，你只需提供一个 app.py 和 requirements.txt ，它就能自动生成带UI的Web页面。它的“免费”体现在：每月1000小时GPU使用时长（T4级别）、无限HTTP请求、自带HTTPS证书、支持Git同步更新。但限制也很明确： 你无法控制服务器进程、不能自定义Nginx配置、不支持WebSocket长连接、且所有代码公开可见 。我去年帮一个医疗影像小组部署肺结节分割模型时选了这条路——他们用MONAI训练了一个UNet，模型权重186MB，推理耗时单图2.3秒。我们直接用Gradio的 Image 组件+ Plot 组件封装， requirements.txt 里加了 monai==1.3.0 和 torchvision==0.18.0 。Spaces自动拉取CUDA镜像，构建耗时4分12秒，上线后URL形如 https://xxx.hf.space 。用户上传DICOM转PNG后，页面实时显示分割热力图。但问题很快出现：当用户连续上传5张图时，后台报错 CUDA out of memory ——因为Spaces默认只分配16GB显存，而UNet推理峰值显存占用达19.2GB。解决方案不是升级硬件（免费层不支持），而是我们在 app.py 里强制添加了 torch.cuda.empty_cache() 并在每次推理前手动释放缓存，同时将batch size硬编码为1。这是典型的“用代码换资源”的免费策略。如果你的模型是文本分类、情感分析、小型CV模型（ResNet18以下），且不需要定制前端样式，Spaces是首选。它不是生产环境，但胜在“5分钟从代码到可分享链接”。

2.2 Streamlit Cloud：最适合数据科学家做内部工具，但需Python生态兼容

Streamlit Cloud 的免费层提供无限应用、每月10小时活跃时长（非总运行时长）、共享CPU资源、自动HTTPS。它和Spaces的关键差异在于： Streamlit要求你用Python写声明式UI，所有交互逻辑必须内嵌在 .py 文件中，且不支持原生JavaScript扩展 。这意味着，如果你的前端需要复杂图表（如ECharts联动）、拖拽上传、或离线PWA功能，Streamlit Cloud会把你逼疯。但它对数据科学工作流极其友好。我上个月帮一家电商公司部署销量预测看板，他们用Prophet训练了12个SKU的时间序列模型，每个模型保存为 .pkl 文件。我们用Streamlit写了一个 dashboard.py ：顶部放 st.selectbox 选SKU，中间 st.line_chart 画历史销量+预测区间，底部 st.download_button 导出CSV。 requirements.txt 只写了 streamlit==1.35.0 和 prophet==1.1.5 。部署时，我们把整个项目推到GitHub私有库，再在Streamlit Cloud控制台绑定仓库，它自动检测 requirements.txt 并构建。难点在于Prophet依赖 pystan ，而pystan在Streamlit Cloud的Ubuntu 22.04环境里编译失败。最终方案是：我们改用 prophet==1.1.5 的wheel包（提前在相同系统里 pip wheel prophet 生成），把 dist/prophet-1.1.5-py3-none-any.whl 放入项目根目录，在 requirements.txt 里写 ./prophet-1.1.5-py3-none-any.whl 。构建成功。这里的关键洞察是：Streamlit Cloud的“免费”本质是 用标准化环境换免运维 ，你要做的不是适配它，而是让自己的代码去适配它的环境约束。它不适合做高并发API网关，但极适合做“给老板演示用的周报看板”或“给销售团队查库存的内部小工具”。

2.3 GitHub Pages + Flask API（Cloudflare Workers后端）：最适合需要完全控制前端的轻量级应用

这条路径是真正意义上的“前后端分离免费部署”。前端用HTML/CSS/JS写，托管在GitHub Pages（完全免费、CDN加速、HTTPS强制）；后端API用Flask/FastAPI写，但 不自己租服务器，而是部署到Cloudflare Workers 。Cloudflare Workers的免费层提供每月10万次请求、10ms CPU时间上限、50KB脚本大小限制。听起来很苛刻？但对ML推理而言，它恰恰卡在“轻量模型”的黄金分割点上。我们曾为一个高校NLP课设部署BERT-base中文文本相似度服务：模型用Hugging Face transformers 加载，但直接跑在Workers上会超内存（Workers最大内存512MB）。解决方案是：用ONNX Runtime Web（ onnxruntime-web ）把模型转成WebAssembly，在前端浏览器里做推理。但学生反馈“手机上加载慢”。于是我们改用Cloudflare Workers + @xenova/transformers （Xenova团队优化的轻量版Transformers.js），它把BERT-base压缩到12MB，Workers脚本里只做tokenize→run→decode三步，全程在V8引擎里执行，不碰GPU。 wrangler.toml 配置里，我们设置 compatibility_date = "2024-05-01" 启用最新API， bindings 里挂载KV存储存用户调用日志（免费层1000次写入/天）。前端GitHub Pages页面通过 fetch("https://xxx.workers.dev/similarity", {method: "POST", body: JSON.stringify({text1, text2})}) 调用。整个链路零服务器、零运维、零月费。它的代价是：你必须接受Workers的10ms CPU限制，因此模型必须足够轻——我们实测，DistilBERT、ALBERT-base、TinyBERT在此框架下稳定，而RoBERTa-large会超时。这不是妥协，而是精准匹配：用边缘计算的低延迟特性，换掉中心化GPU服务器的高成本。

2.4 Render.com 免费Web Service（带PostgreSQL）：最适合需要数据库状态的全栈应用

Render.com 的免费Web Service提供无限请求、512MB RAM、0.1 vCPU、自带PostgreSQL（免费层10MB数据库），且支持自定义Dockerfile。它不像Heroku那样强制要求Procfile，也不像Vercel那样只认前端框架。我们用它部署了一个“AI简历解析器”：用户上传PDF，后端用 pdfplumber 提取文本， spaCy 做实体识别，结果存入PostgreSQL，前端用React展示结构化数据。关键点在于Dockerfile优化：基础镜像不用 python:3.11-slim （太大），而用 continuumio/anaconda3:2023.07 （预装NumPy/Pandas，减少 pip install 时间）； COPY 指令把 requirements.txt 单独COPY再RUN pip install，利用Docker layer cache；最后 CMD ["gunicorn", "--bind", "0.0.0.0:10000", "app:app"] 。构建日志显示，首次部署耗时6分33秒，后续更新因cache复用缩至1分48秒。免费层的512MB RAM是瓶颈—— pdfplumber 解析10页PDF峰值内存达480MB。我们加了 try/except MemoryError 捕获，并返回 {"error": "PDF too large, max 5 pages"} 。Render的真正价值在于：它让你用免费资源获得接近生产环境的体验。你可以SSH进实例（Render不开放，但可通过 render-cli debug）、看实时日志、设环境变量、绑自定义域名。如果你的应用需要用户登录、数据持久化、或定时任务（用Render Cron Jobs免费层），Render是目前免费方案里最接近“正经后端”的选择。

3. 模型服务化的核心技术细节与避坑指南

无论选哪条路径，“把模型变成API”都不是 pickle.load() 然后 return model.predict() 这么简单。真正的难点藏在模型加载、请求处理、错误兜底这三个环节。下面是我整理的通用技术细节，已适配上述四条路径。

3.1 模型加载：别让冷启动毁掉首请求体验

所有免费平台都有“冷启动”问题：应用空闲一段时间后，实例被休眠，首个请求需重新加载模型，耗时可能长达10~30秒。用户看到的是白屏或超时错误。解决方案不是加钱买常驻实例（免费层不支持），而是 预热+懒加载+缓存 三重策略。以Flask为例，在 app.py 顶部：

import threading
import time
from transformers import AutoTokenizer, AutoModelForSequenceClassification

# 全局变量存模型和tokenizer，避免每次请求都加载
_model = None
_tokenizer = None

def load_model():
    global _model, _tokenizer
    # 在后台线程加载，不阻塞主线程
    def _load():
        start = time.time()
        _tokenizer = AutoTokenizer.from_pretrained("uer/roberta-finetuned-jd-binary-chinese")
        _model = AutoModelForSequenceClassification.from_pretrained("uer/roberta-finetuned-jd-binary-chinese")
        print(f"[INFO] Model loaded in {time.time() - start:.2f}s")
    threading.Thread(target=_load, daemon=True).start()

# 启动时触发预热
load_model()

@app.route("/predict", methods=["POST"])
def predict():
    global _model, _tokenizer
    # 检查模型是否加载完成，未完成则返回503
    if _model is None or _tokenizer is None:
        return {"error": "Model loading, try again in 5s"}, 503
    
    data = request.get_json()
    inputs = _tokenizer(data["text"], return_tensors="pt", truncation=True, max_length=128)
    outputs = _model(**inputs)
    probs = torch.nn.functional.softmax(outputs.logits, dim=-1)
    return {"label": probs.argmax().item(), "confidence": probs.max().item()}

这段代码的关键在于： threading.Thread 确保模型加载不阻塞Flask主线程； daemon=True 让线程随主进程退出； 503 状态码告诉前端“稍等，正在热身”。在Hugging Face Spaces里，你不能用 threading （沙箱限制），改用 @spaces.gradio.app.on_startup 装饰器；在Cloudflare Workers里，则用 addEventListener('install', ...) 在安装阶段加载模型权重到内存。冷启动不是bug，是免费资源的物理定律，你只能优雅地与之共处。

3.2 请求处理：别让单个坏请求拖垮整个服务

免费平台资源有限，一个恶意请求（如上传2GB文件、发送超长文本）可能直接OOM。必须在入口层做严格校验。以FastAPI为例，我们加了三层防护：

from fastapi import FastAPI, HTTPException, Depends
from pydantic import BaseModel
from typing import Optional

class PredictionRequest(BaseModel):
    text: str
    # 用Pydantic的validator做长度限制
    @validator('text')
    def text_must_be_short(cls, v):
        if len(v) > 512:
            raise ValueError('text must be <= 512 characters')
        return v

app = FastAPI()

@app.post("/predict")
async def predict(request: PredictionRequest):
    # 第二层：检查Content-Length头（防止大文件）
    if int(request.headers.get("content-length", "0")) > 1024 * 1024:  # 1MB
        raise HTTPException(status_code=413, detail="Payload too large")
    
    # 第三层：超时控制
    try:
        result = await asyncio.wait_for(
            run_inference(request.text), 
            timeout=10.0  # 10秒硬超时
        )
        return result
    except asyncio.TimeoutError:
        raise HTTPException(status_code=408, detail="Inference timeout")

这里 @validator 在Pydantic解析阶段就拦截超长文本； content-length 检查在ASGI中间件层拦截大请求； asyncio.wait_for 在业务逻辑层设超时。三者缺一不可。我在Render部署时遇到过真实案例：一个爬虫持续发 text="" 空字符串请求，导致 tokenizer 内部报错崩溃。后来我们在 @validator 里加了 if not v.strip(): raise ValueError("text cannot be empty") 才解决。免费部署的哲学是： 假设所有输入都是恶意的，然后用最小成本过滤掉99%的坏请求 。

3.3 错误兜底：用户看到的不该是500，而应是“我知道哪里错了”

免费平台日志不透明（如Spaces只显示最后100行），你无法像在本地一样 print() 调试。必须把错误转化为用户可理解的提示，并记录关键上下文。我们统一用结构化日志：

import logging
import traceback
import json

# 配置JSON格式日志，方便后期grep
logging.basicConfig(
    level=logging.INFO,
    format='{"time": "%(asctime)s", "level": "%(levelname)s", "message": "%(message)s", "traceback": "%(exc_text)s"}',
    datefmt='%Y-%m-%d %H:%M:%S'
)

@app.post("/predict")
def predict():
    try:
        data = request.get_json()
        # ... 业务逻辑
        return {"result": result}
    except ValueError as e:
        # 用户输入错误，返回400
        logging.warning(f"ValueError: {str(e)} | data={json.dumps(data)[:100]}")
        return {"error": "Invalid input", "detail": str(e)}, 400
    except torch.cuda.OutOfMemoryError:
        # GPU内存不足，返回503并建议降级
        logging.error(f"CUDA OOM | data_len={len(data.get('text', ''))}")
        return {"error": "Server busy", "hint": "Try shorter text"}, 503
    except Exception as e:
        # 未知错误，记录完整traceback
        logging.error(f"Unexpected error: {str(e)} | {traceback.format_exc()}")
        return {"error": "Internal error"}, 500

重点在 logging.error 里 traceback.format_exc() ——它把完整堆栈打出来，哪怕日志被截断，你也能看到 File "model.py", line 45, in forward 这一行。在实际项目中，我们还加了 request_id （用 uuid.uuid4() 生成）贯穿整个请求，在日志里搜索 request_id 就能串起所有操作。免费不等于粗糙，而是用更聪明的日志设计弥补可观测性的缺失。

4. 实操全流程：从本地开发到线上可访问的7步闭环

现在，我们以一个具体项目——“新闻标题情感分析Web App”为例，走一遍从零到上线的完整流程。模型用 bert-base-chinese 微调，前端用Vue3，后端用FastAPI，部署到Render.com免费Web Service。所有步骤均经实测，命令可直接复制粘贴。

4.1 步骤1：本地开发环境初始化（5分钟）

创建项目目录，初始化虚拟环境：

mkdir news-sentiment-app && cd news-sentiment-app
python3 -m venv venv
source venv/bin/activate  # macOS/Linux
# venv\Scripts\activate  # Windows
pip install --upgrade pip
pip install fastapi uvicorn transformers torch scikit-learn pandas numpy

注意：不要 pip install tensorflow ——它太大，Render构建会超时。我们用PyTorch，体积小30%。 transformers 版本锁定为 4.41.2 （2024年6月最新稳定版），避免未来API变更。

4.2 步骤2：模型训练与导出（30分钟，含验证）

我们用公开的ChnSentiCorp数据集（中文情感二分类）。训练脚本 train.py 核心逻辑：

from transformers import Trainer, TrainingArguments
from datasets import load_dataset

dataset = load_dataset("chnsenticorp")
model = AutoModelForSequenceClassification.from_pretrained("bert-base-chinese", num_labels=2)
tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese")

def tokenize_function(examples):
    return tokenizer(examples["text"], truncation=True, padding=True, max_length=128)

tokenized_datasets = dataset.map(tokenize_function, batched=True)
training_args = TrainingArguments(
    output_dir="./results",
    num_train_epochs=3,
    per_device_train_batch_size=16,
    per_device_eval_batch_size=16,
    warmup_steps=500,
    weight_decay=0.01,
    logging_dir='./logs',
    save_strategy="no",  # 免费部署不需保存中间检查点
)

trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=tokenized_datasets["train"],
    eval_dataset=tokenized_datasets["test"],
)
trainer.train()

# 导出为ONNX（更小更快）
from transformers import pipeline
import torch.onnx

# 创建推理pipeline
pipe = pipeline("text-classification", model=model, tokenizer=tokenizer, device=0 if torch.cuda.is_available() else -1)
# ONNX导出（简化版，实际需用torch.onnx.export详细参数）
torch.onnx.export(
    pipe.model,
    (torch.randint(0, 1000, (1, 128)), torch.ones(1, 128, dtype=torch.long)),
    "model.onnx",
    input_names=["input_ids", "attention_mask"],
    output_names=["logits"],
    dynamic_axes={"input_ids": {0: "batch_size"}, "attention_mask": {0: "batch_size"}},
    opset_version=14
)

训练完成后， model.onnx 大小为412MB（比原始PyTorch模型小18%）， tokenizer.json 存为 tokenizer.json 。我们删掉 ./results 目录，只留 model.onnx 和 tokenizer.json 。

4.3 步骤3：FastAPI后端编写（15分钟）

创建 app.py ：

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from transformers import AutoTokenizer
import onnxruntime as ort
import numpy as np
import torch

class SentimentRequest(BaseModel):
    title: str

app = FastAPI(title="News Sentiment API")

# 加载ONNX模型和tokenizer
ort_session = ort.InferenceSession("model.onnx", providers=['CPUExecutionProvider'])  # 强制CPU，Render无GPU
tokenizer = AutoTokenizer.from_pretrained(".")

@app.post("/analyze")
def analyze_sentiment(request: SentimentRequest):
    if not request.title.strip():
        raise HTTPException(status_code=400, detail="Title cannot be empty")
    if len(request.title) > 128:
        raise HTTPException(status_code=400, detail="Title too long, max 128 chars")
    
    # Tokenize
    inputs = tokenizer(
        request.title,
        return_tensors="np",
        truncation=True,
        padding=True,
        max_length=128
    )
    
    # ONNX推理
    try:
        ort_inputs = {
            "input_ids": inputs["input_ids"].astype(np.int64),
            "attention_mask": inputs["attention_mask"].astype(np.int64)
        }
        ort_outs = ort_session.run(None, ort_inputs)
        logits = ort_outs[0]
        probs = torch.nn.functional.softmax(torch.tensor(logits), dim=-1)
        label = probs.argmax().item()
        confidence = probs.max().item()
        
        return {
            "label": "positive" if label == 1 else "negative",
            "confidence": float(confidence),
            "probabilities": {
                "negative": float(probs[0][0]),
                "positive": float(probs[0][1])
            }
        }
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"Inference failed: {str(e)}")

关键点： providers=['CPUExecutionProvider'] 确保在Render的CPU环境运行； return_tensors="np" 直接输出NumPy数组，避免PyTorch依赖；所有异常都包装成 HTTPException ，前端好处理。

4.4 步骤4：Dockerfile编写与本地测试（20分钟）

创建 Dockerfile ：

FROM continuumio/anaconda3:2023.07

# 复制requirements.txt先安装，利用layer cache
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 复制模型和代码
COPY model.onnx .
COPY tokenizer.json .
COPY app.py .

# 安装ONNX Runtime CPU版（比默认pip包小）
RUN pip install --no-cache-dir onnxruntime==1.18.0

# 暴露端口
EXPOSE 10000

# 启动命令
CMD ["uvicorn", "app:app", "--host", "0.0.0.0:10000", "--port", "10000", "--workers", "1"]

requirements.txt 内容：

fastapi==0.111.0
uvicorn==0.29.0
numpy==1.26.4
onnxruntime==1.18.0

本地测试：

docker build -t news-sentiment .
docker run -p 10000:10000 news-sentiment
# 访问 http://localhost:10000/docs 测试Swagger UI
curl -X 'POST' 'http://localhost:10000/analyze' \
  -H 'Content-Type: application/json' \
  -d '{"title":"今天股市大涨，投资者信心恢复"}'
# 返回 {"label":"positive","confidence":0.98,...}

4.5 步骤5：GitHub仓库初始化与Render绑定（10分钟）

git init
git add .
git commit -m "initial commit"
git branch -M main
git remote add origin https://github.com/yourname/news-sentiment-app.git
git push -u origin main

登录Render.com → “New Web Service” → 选择GitHub仓库 → 设置环境：

• Service Name : news-sentiment-api
• Region : Oregon （离中国用户最近）
• Branch : main
• Build Command : echo "build done" （我们用Dockerfile，无需额外build）
• Start Command : uvicorn app:app --host 0.0.0.0:$PORT --port $PORT --workers 1
• Environment Variables : PORT=10000 （Render会注入实际PORT）

点击“Create Web Service”。Render自动拉取代码、构建Docker镜像、启动容器。构建日志里看到 Successfully built xxx 即成功。

4.6 步骤6：前端Vue3开发与GitHub Pages部署（25分钟）

创建 frontend/ 目录，用Vite初始化：

npm create vite@latest frontend -- --template vue
cd frontend
npm install

修改 src/App.vue ，加入调用API的逻辑：

<script setup>
import { ref, onMounted } from 'vue'

const title = ref('')
const result = ref(null)
const loading = ref(false)
const error = ref(null)

const analyze = async () => {
  if (!title.value.trim()) return
  loading.value = true
  error.value = null
  try {
    const res = await fetch('https://news-sentiment-api.onrender.com/analyze', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ title: title.value })
    })
    if (!res.ok) throw new Error(`HTTP ${res.status}`)
    result.value = await res.json()
  } catch (e) {
    error.value = e.message
  } finally {
    loading.value = false
  }
}

onMounted(() => {
  // 自动聚焦输入框
  document.getElementById('title-input').focus()
})
</script>

<template>
  <div class="container">
    <h1>📰 新闻标题情感分析</h1>
    <input 
      id="title-input" 
      v-model="title" 
      placeholder="输入新闻标题，例如：苹果发布新款iPhone，销量破纪录" 
      @keyup.enter="analyze"
    />
    <button @click="analyze" :disabled="loading">
      {{ loading ? '分析中...' : '分析情感' }}
    </button>
    <div v-if="error" class="error">❌ {{ error }}</div>
    <div v-if="result" class="result">
      <div class="label">{{ result.label === 'positive' ? '😊 积极' : '😞 消极' }}</div>
      <div class="confidence">置信度: {{ (result.confidence * 100).toFixed(1) }}%</div>
      <div class="probs">
        消极: {{ (result.probabilities.negative * 100).toFixed(1) }}% | 
        积极: {{ (result.probabilities.positive * 100).toFixed(1) }}%
      </div>
    </div>
  </div>
</template>

构建并部署到GitHub Pages：

npm run build
# 将dist目录推送到gh-pages分支
npx gh-pages -d dist -b gh-pages

在GitHub仓库Settings → Pages → Branch选 gh-pages → Save。几分钟后，访问 https://yourname.github.io/news-sentiment-app/ 即可使用。

4.7 步骤7：联调与性能压测（15分钟）

前端调用Render后端时，需处理CORS。在 app.py 里加：

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://yourname.github.io"],  # 替换为你的真实域名
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

用 k6 做简单压测（免费开源）：

# 安装k6
brew install k6  # macOS

# 创建test.js
echo 'import http from "k6/http"; export default function () { http.post("https://news-sentiment-api.onrender.com/analyze", JSON.stringify({title:"测试标题"}), {headers: {"Content-Type": "application/json"}}); }' > test.js

# 压测：10个虚拟用户，持续30秒
k6 run -u 10 -d 30s test.js

实测Render免费层在10并发下，P95延迟<800ms，成功率100%。当并发升到20时，开始出现503（内存超限），符合预期。此时我们加了前端防抖： v-on:click="debounce(analyze, 300)" ，避免用户狂点。

5. 常见问题速查表与独家避坑技巧

在27个免费部署项目中，92%的问题集中在以下10类。我把它们整理成速查表，并附上只有踩过坑的人才知道的技巧。

最后分享一个小技巧 ：所有免费部署平台都提供“自定义域名”功能（如Render支持 yourname.onrender.com ，GitHub Pages支持 yourname.github.io ）。但用户信任度取决于URL。我的