1. 什么是 demo它不是“演示视频”那么简单“demo 是什么”——这个问题在技术团队晨会、产品需求评审、实习生入职培训里几乎每天都在被问。但很多人听到答案后反而更迷糊有人说“就是个样机”有人说“是给老板看的 PPT 动画”还有人直接甩出一句“不就是个假后台连着静态页面嘛”。这些说法不算错但就像说“汽车就是四个轮子加铁壳”一样漏掉了最关键的骨架、动力逻辑和真实用途。在我带过的 23 个跨行业项目里从智能硬件原型到政务服务平台 MVP再到独立游戏早期版本demo 的本质从来不是“展示”而是“可验证的最小决策支点”。它不追求功能完整但必须能回答三个硬问题这个想法在技术上是否走得通用户真的会为这个交互停留 3 秒以上吗市场反馈数据能否支撑下一步投入——这三点决定了 demo 是烧掉 5 万还是省下 50 万。你可能已经见过 demo 的各种形态嵌入式设备上跑着没外壳的 PCB 板后台只返回写死的 JSON 字符串SaaS 系统里一个只有登录页和空白仪表盘的 React 前端所有按钮点击都弹出 alert(‘coming soon’)甚至是一段用 Excel 模拟的订单流转流程靠人工填表触发“状态变更”。它们看起来简陋但背后都有明确的设计意图用最低成本暴露最大风险。比如我去年帮一家社区团购公司做履约调度 demo没写一行调度算法而是用颜色标记的 Excel 表格模拟 3 个骑手在 5 个小区间的路径选择让运营主管当场指出“这个红标小区根本没电梯骑手不可能 8 分钟内送达”——这个发现直接让团队砍掉了原定的 AI 路径规划模块转而优化了派单规则引擎。这才是 demo 的真实价值它不是给外人看的花架子而是给自己人照的 X 光片。关键词“demo”之所以持续登上技术类热搜恰恰因为它处在“想法”和“产品”之间最脆弱也最关键的断层带上。很多团队失败不是因为技术不行而是把 demo 当成了“简化版成品”结果在客户面前演示时数据库连接超时、第三方 API 返回空值、UI 在 iPhone 上错位——这些本该在 demo 阶段就暴露的问题拖到了交付现场才爆发。所以今天这篇内容不讲定义不列教科书分类只拆解一个真正有用的 demo到底该怎么设计、怎么造、怎么用。如果你正要启动新项目、要向投资人汇报、或是刚接手一个需求模糊的旧系统改造接下来的内容每一步都能直接抄作业。2. demo 的核心设计逻辑为什么不能“先做个界面再补逻辑”2.1 demo 不是 MVP更不是原型图——三者的生死线在哪很多团队混淆 demo、MVPMinimum Viable Product和原型图Prototype结果在资源分配上严重失衡。我用一个真实案例说明区别去年某教育科技公司要做“AI 口语陪练”项目三者分工如下原型图产品经理用 Figma 画的 8 页交互流程包含点击麦克风图标→录音波形动画→AI 打分弹窗→错误发音高亮。它只回答“用户操作路径是否顺畅”不涉及任何真实数据或逻辑连录音权限都没申请。demo前端用 Web Speech API 实现真实录音仅支持 Chrome后端用 Python 写了个 30 行脚本把语音转文字后硬编码匹配 5 个常见错误句型如 “He go to school” → 提示 “go 应为 goes”。整个系统只部署在一台 2 核 4G 的云服务器上所有数据存在内存字典里重启即清空。它要验证的是“实时语音识别规则匹配”这条路在当前算力和网络条件下延迟能否控制在 1.2 秒内实测 1.07 秒。MVP上线了真实用户注册、课程购买、7 天免费试用接入了商用语音识别 API错误分析模型覆盖 120 个语法点数据库用 PostgreSQL 存储用户练习记录。它要回答的是“付费转化率是否达到 3.5%”、“次日留存是否超过 28%”。提示判断你做的东西是不是真 demo就看它是否具备“可破坏性验证”能力——你能故意制造一个边界条件比如传入 10MB 的音频文件、并发 500 个请求、输入含 200 个 emoji 的句子然后清晰看到系统哪条链路最先崩溃。原型图做不到这点MVP 也不敢这么干。2.2 demo 的黄金三角真实性、可控性、可弃性一个合格 demo 必须同时满足三个条件缺一不可真实性Authenticity它处理的是真实数据流哪怕只是模拟。比如做支付 demo不能只弹窗显示“支付成功”而要让前端真实调用支付宝沙箱接口拿到真实的trade_no和out_trade_no哪怕后端不走真实账务系统。我见过太多团队用return { success: true }模拟支付结果上线后发现沙箱环境的签名算法和正式环境有细微差异导致联调卡了三天。可控性Controllability所有变量必须能手动干预。比如做推荐系统 demo不能只写“猜你喜欢”模块而要提供一个开关开启时返回预设的 3 个商品 ID模拟冷启动关闭时返回随机 5 个商品模拟无策略状态。这样产品才能对比两种逻辑对点击率的影响。我们曾用这种开关发现用户对“猜你喜欢”的点击率比“新品首发”低 47%直接推翻了最初的推荐权重设计。可弃性Disposability代码、配置、数据必须能在 10 分钟内彻底删除不留痕迹。这意味着 demo 不能复用生产环境的数据库连接池不能共享 Redis 实例甚至不能共用同一个 Git 分支。我们强制要求所有 demo 项目使用独立域名如 demo-pay.yourcompany.dev、独立子目录/demo/v1、独立配置文件config.demo.json上线前用 shell 脚本自动检查是否存在生产环境敏感字段如DB_PASSWORD、ALIYUN_OSS_SECRET发现即报错退出。这三个特性共同指向一个目标让 demo 成为安全的“压力测试沙盒”而不是埋进主干的定时炸弹。去年有个团队把 demo 的 mock 接口代码合并进了生产分支结果某次大促期间因流量激增触发了 mock 逻辑里的内存泄漏导致订单创建成功率暴跌。根源就在于 demo 缺失“可弃性”设计。2.3 demo 的四种致命误区——90% 的团队至少踩中两个根据我参与的 47 次项目复盘团队在 demo 设计中最常犯的错误有四类按危害程度排序误区类型典型表现后果真实案例过度工程化用微服务架构搭 demo每个模块都配 Prometheus 监控、Jaeger 链路追踪开发周期拉长 3 倍核心逻辑未验证就陷入运维配置某 IoT 团队花 2 周搭 Kafka Flink 流处理 demo结果发现传感器原始数据格式根本无法解析返工重写解析器虚假真实性前端调用真实 API但后端用if (Math.random() 0.5) return mockData模拟失败场景无法复现偶发错误调试时怀疑网络、怀疑浏览器、怀疑自己支付 demo 中 20% 请求返回超时开发以为是网络问题实际是 mock 逻辑里写了setTimeout(() { throw new Error(timeout) }, 3000)边界缺失demo 只测试“理想路径”不验证空输入、超长文本、特殊字符、网络中断上线后首日崩溃错误日志显示Cannot read property length of null社交 App demo 未测试用户名为空上线后大量用户注册失败客服电话被打爆责任模糊产品经理说“技术实现 demo”开发说“产品给清需求”测试说“没需求文档不测”demo 无人负责最终变成“能跑就行”的半成品某 SaaS 工具 demo 缺少权限校验客户演示时误删了全部数据合同谈判直接终止这些误区背后是团队对 demo 定位的根本性偏差把它当成“阶段性交付物”而非“持续验证工具”。真正的 demo 应该像一把手术刀——每次使用前消毒重置环境每次切口精准聚焦单一验证点每次用完即弃不污染主干。下一节我们就从实操层面拆解如何亲手打造这样一把刀。3. 实操指南从零搭建一个可验证 demo 的完整流程3.1 第一步用“一句话验证清单”锁定 demo 核心目标别急着写代码。在打开编辑器前必须完成这个动作用一句话写下 demo 要验证的唯一核心假设并列出 3 个可量化的验证指标。这句话模板是“当 [用户/系统] 执行 [具体动作] 时[关键结果] 应在 [时间/精度/成功率] 内发生否则证明 [假设] 不成立。”举几个不同领域的例子硬件领域当温湿度传感器在 35℃ 环境下连续工作 2 小时其 ADC 采样值漂移应小于 ±0.5%否则证明选型的运放温漂参数不满足工业级要求。AI 领域当上传一张 1920×1080 的 JPG 人脸图模型返回的 5 个关键点坐标误差应小于 3 像素以标注框为基准否则证明训练数据增强策略失效。Web 应用当 100 个用户同时点击“生成报告”按钮服务器响应时间应 ≤800ms且错误率 0.1%否则证明当前 Node.js 单线程模型无法承载业务峰值。这个清单必须由技术负责人、产品经理、测试工程师三方签字确认。我坚持这个流程是因为它能瞬间过滤掉“为了 demo 而 demo”的伪需求。曾经有个团队要做“区块链存证 demo”最初目标写的是“实现数据上链”签字时被测试工程师拦下“上链成功算验证通过还是需要验证哈希值可被第三方浏览器查到还是需要验证 10 分钟后仍可查询”——最后目标修正为“当用户上传 PDF 文件系统返回的交易哈希值能在 Etherscan 浏览器中查到对应区块且区块确认数 ≥12”这才进入开发。注意这个清单不是固定不变的。我们在 demo 过程中发现新风险会立刻追加验证项。比如上述区块链 demo 中测试发现某些 PDF 的 SHA256 哈希计算耗时超预期立即新增一条“PDF 文件大小在 1MB~10MB 区间时哈希计算时间应 ≤200ms”。3.2 第二步环境搭建——用 Docker Compose 实现“开箱即用”demo 环境必须做到新人 clone 代码后执行一条命令就能跑起来且所有依赖版本锁定。我们弃用 VM 和手动安装统一用 Docker Compose原因很实在版本确定性Node.js 16.14.2、Python 3.9.16、PostgreSQL 14.5 —— 这些数字不是随便写的而是线上环境已验证的稳定组合。Docker 镜像标签精确到 patch 版本如node:16.14.2-alpine避免node:16这种标签带来的隐性升级风险。隔离性保障每个 demo 服务独占一个 Docker 网络用docker network create demo-net创建所有容器通过 service name 通信如db、api不暴露任何端口到宿主机彻底杜绝端口冲突。销毁便捷性docker-compose down -v一条命令清除所有容器、网络、卷比手动删进程、清端口、卸载软件快 10 倍。以下是我们标准 demo 的docker-compose.yml骨架已脱敏version: 3.8 services: # 前端服务Nginx 静态托管禁用缓存便于调试 web: image: nginx:1.23.3-alpine ports: - 8080:80 volumes: - ./dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - api # 后端服务Python FastAPI带健康检查 api: build: context: ./backend dockerfile: Dockerfile.demo environment: - ENVdev - DB_URLpostgresql://demo:demodb:5432/demo - REDIS_URLredis://cache:6379/0 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 depends_on: - db - cache # 数据库PostgreSQL初始化脚本预置测试数据 db: image: postgres:14.5-alpine environment: - POSTGRES_DBdemo - POSTGRES_USERdemo - POSTGRES_PASSWORDdemo volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql - pgdata:/var/lib/postgresql/data # 缓存Redis禁用持久化 cache: image: redis:7.0.12-alpine command: redis-server --save --appendonly no healthcheck: test: [CMD, redis-cli, ping] interval: 30s timeout: 10s retries: 3 volumes: pgdata:关键细节说明./init.sql文件里只有一条INSERT INTO users (id, name) VALUES (1, demo_user);确保 demo 启动就有基础数据避免前端报 404。Dockerfile.demo中明确指定python:3.9.16-slim基础镜像并用pip install -r requirements.txt --no-cache-dir安装依赖防止 pip 缓存引入未知版本。所有服务的healthcheck都启用docker-compose up会等待所有服务健康后才结束避免前端启动时后端还没 ready。这套方案实测下来新人入职第一天就能独立跑通 demo平均耗时 4 分钟 23 秒含 Docker Desktop 启动时间。而过去手动配置环境平均要花 3 小时还经常卡在 OpenSSL 版本冲突上。3.3 第三步核心逻辑实现——用“三明治结构”写 demo 代码demo 代码不是越短越好而是要像三明治一样分层清晰顶层是真实入口HTTP 接口/硬件引脚底层是真实输出数据库写入/电机转动中间层是可插拔的验证逻辑。这样既能保证真实性又方便快速切换策略。以一个“智能灌溉 demo”为例验证土壤湿度低于阈值时水泵是否启动# backend/main.py from fastapi import FastAPI from pydantic import BaseModel import asyncio app FastAPI() # 【顶层】真实硬件接口抽象 class HardwareController: async def read_soil_moisture(self) - float: # 真实读取 GPIO 引脚电压转换为 0~100% 湿度值 # 此处为简化实际调用 board.read_analog_pin(0) return 23.7 # 模拟干燥土壤 async def start_pump(self) - bool: # 真实控制继电器闭合此处为简化 print(PUMP STARTED) return True # 【中间层】可插拔的验证逻辑demo 的核心 class MoistureStrategy: def __init__(self, threshold: float 30.0): self.threshold threshold def should_water(self, current_moisture: float) - bool: # 这里可以替换为不同算法规则引擎、简单阈值、ML 模型 return current_moisture self.threshold # 【底层】真实执行与验证 app.post(/water) async def trigger_watering(): hw HardwareController() strategy MoistureStrategy(threshold30.0) # 可随时修改阈值 moisture await hw.read_soil_moisture() if strategy.should_water(moisture): success await hw.start_pump() return {status: watering_started, moisture: moisture, success: success} else: return {status: no_action_needed, moisture: moisture} # 【额外验证】提供手动触发接口绕过传感器 app.post(/water/force) async def force_water(): hw HardwareController() success await hw.start_pump() return {status: forced_watering, success: success}这个结构的优势在于验证聚焦MoistureStrategy类完全独立可单独单元测试验证不同阈值下的决策逻辑。快速迭代想测试机器学习模型只需继承MoistureStrategy重写should_water方法注入新实例即可无需改硬件层。故障隔离如果水泵没启动先调用/water/force接口若成功则问题在传感器读取或策略判断若失败则问题在硬件控制层。我们用这套结构在 3 天内完成了 5 种灌溉策略的 demo 验证最终选定“动态阈值历史均值”方案比原计划提前 11 天。3.4 第四步数据验证——不用埋点用“三色日志”看穿系统demo 的数据验证不能依赖生产环境的监控系统如 Grafana而要用最原始但最有效的方式日志。我们推行“三色日志”规范让每个关键节点的状态一目了然绿色日志INFO正常流程节点如Sensor reading: 23.7%、Pump started successfully黄色日志WARNING边界情况但未失败如Moisture 29.9% is near threshold 30.0%, skipping action、Cache miss for user_id123红色日志ERROR真实异常必须人工介入如Failed to read GPIO pin 0: timeout after 500ms、Database connection refused关键技巧所有日志必须包含可追溯的 trace_id。我们在每个请求头注入X-Trace-ID并在日志中打印。例如2023-10-15 14:22:31,123 [INFO] [trace-id:abc123] Sensor reading: 23.7% 2023-10-15 14:22:31,456 [WARNING] [trace-id:abc123] Moisture 29.9% is near threshold 30.0% 2023-10-15 14:22:31,789 [INFO] [trace-id:abc123] Pump started successfully这样当客户演示时出现异常我们只要拿到 trace-id就能在 10 秒内定位到完整调用链。去年某次政府项目演示客户突然说“报告生成慢”我们拿到 trace-id 后发现是 Redis 连接池耗尽原因是 demo 里忘了设置max_connections10而默认是 100——这个配置在生产环境没问题但在 demo 的轻量级 Redis 实例上直接打满。如果没有 trace_id排查至少要 2 小时。实操心得日志级别不是越多越好。我们禁止在 demo 中使用 DEBUG 级别因为 demo 本就不该有复杂调试逻辑也禁止在 ERROR 日志里打印堆栈太占篇幅而是用logger.exception(Failed to start pump)记录既保留上下文又不刷屏。4. demo 的实战应用从需求评审到融资路演的 7 个关键场景4.1 场景一需求评审会——用 demo 替代 20 页 PRD 文档传统 PRD 文档最大的问题是产品经理认为用户要 A 功能开发理解成 B 实现测试验收时发现是 C 效果。而 demo 能让所有人站在同一事实基础上讨论。我们的做法是在需求评审会前 2 天交付一个“可交互 demo”它只包含本次评审的核心流程其他模块用灰色遮罩提示文字如“此处将接入 CRM 系统”。会议中产品经理用鼠标操作 demo每点击一步就同步讲解业务规则开发实时指出技术约束如“这个搜索框要支持中文分词需引入 Elasticsearch”测试当场提出验证点如“输入 100 个汉字时页面是否卡顿”。效果立竿见影某电商项目的需求评审原计划 4 小时实际 1.5 小时结束且后续开发中需求变更率下降 68%。因为所有模糊点都在 demo 操作中暴露了——比如产品经理说“用户下单后自动发短信”demo 里点下单按钮后弹窗显示“短信发送中...”但 3 秒后变成“短信发送失败运营商限制”这时大家才意识到要提前对接短信通道白名单。4.2 场景二技术方案选型——用 demo 对比三种数据库性能当团队纠结“用 MySQL 还是 MongoDB 存用户行为日志”时不要查文档、不要听厂商宣讲直接写 demo 对比。我们做了这样一个 demo用相同数据集100 万条模拟点击日志含 user_id、page_url、timestamp、duration分别导入 MySQLInnoDB 引擎、MongoDB副本集、TimescaleDB时序优化编写相同查询SELECT COUNT(*) FROM logs WHERE user_id U123 AND timestamp BETWEEN 2023-01-01 AND 2023-01-31结果令人意外MySQL 耗时 1200msMongoDB 850msTimescaleDB 210ms。但当我们增加一个聚合查询SELECT page_url, COUNT(*) FROM logs GROUP BY page_url ORDER BY COUNT(*) DESC LIMIT 10TimescaleDB 耗时 350msMongoDB 1800msMySQL 2400ms。更重要的是插入吞吐量测试显示MongoDB 在 1000 QPS 下稳定MySQL 在 800 QPS 时开始丢包TimescaleDB 在 1500 QPS 下 CPU 占用率已达 92%。这些数据不是理论值而是 demo 实测结果。最终团队选择 TimescaleDB但加了一条约束“必须配置专用 SSD 存储且查询并发数不超过 50”。这个决策依据比任何架构师 PPT 都有说服力。4.3 场景三客户演示——用“故障注入 demo”建立专业信任很多团队怕客户提刁钻问题于是把 demo 做成“完美无瑕”的样子。但真实世界没有完美系统。我们反其道而行之主动设计“故障注入 demo”在演示中自然展示系统韧性。例如给银行做风控 demo我们会准备三个按钮正常模式返回标准审批结果网络延迟模式模拟 2 秒 API 延迟展示 loading 状态和超时提示规则冲突模式故意触发两条互斥规则如“信用分700 通过”和“近 3 月逾期2 次拒绝”展示系统如何加权决策并给出解释客户看到这些第一反应不是质疑而是点头“哦你们考虑了这些情况。” 有一次演示后银行技术总监主动说“我们上次系统升级就栽在没测网络延迟你们这个 demo 让我想起那场事故。”——信任恰恰来自对缺陷的坦诚。4.4 场景四招聘面试——用 demo 代替算法题我们招聘后端工程师时不再考“反转链表”而是给候选人一个 demo 任务“这是一个电商搜索 demo当前只支持关键词匹配。请你在 45 分钟内添加‘同义词扩展’功能如搜‘手机’也返回‘智能手机’结果并验证效果。”候选人要完成修改搜索逻辑可能用 Trie 树或 ElasticSearch Synonym Graph添加测试用例验证“手机”返回含“智能手机”的商品提交 PR 并附上截图这个 demo 考察的是真实工程能力Git 操作、调试技巧、业务理解同义词对电商搜索的意义、沟通能力PR 描述是否清晰。比纯算法题更能预测候选人入职后的表现。我们用此方法招聘的 12 名工程师试用期通过率 100%而传统面试方式的通过率是 63%。4.5 场景五内部培训——用“可破坏 demo”教新人避坑新人培训最怕“纸上谈兵”。我们给新人一个故意留坑的 demo让他们自己发现并修复。例如一个 Flask demo表面功能正常但暗藏三个经典错误app.config[SECRET_KEY] devkey—— 硬编码密钥安全漏洞cursor.execute(SELECT * FROM users WHERE id user_id)—— SQL 注入风险time.sleep(5)模拟耗时操作但没做异步处理导致整个服务阻塞新人拿到后用curl -v http://localhost:5000/user/1测试发现响应慢再用sqlmap -u http://localhost:5000/user/1扫描爆出注入漏洞最后查看代码找到硬编码密钥。这个过程比讲 10 遍安全规范都管用。我们统计过经过这种训练的新人上线代码的 CVE 高危漏洞率为 0.2%远低于行业平均的 3.7%。4.6 场景六融资路演——用 demo 代替财务预测图表投资人最怕听到“预计 2025 年营收 2 亿”。他们更想看到“这个技术现在能不能解决真实痛点”我们的路演 demo 是一个 3 分钟可操作的网页投资人输入自己的公司名demo 自动抓取其官网、招聘页、新闻稿用 NLP 模型分析出“技术关键词热度”如“AI”出现频次、“人才缺口”如“招聘 Java 工程师 12 人”生成一页 PDF 报告包含可验证的数据如“贵司官网中‘云原生’提及次数0 次竞品平均8.3 次”这个 demo 不承诺未来收益但它证明我们的技术能实时、准确地获取和分析非结构化数据。一位投资人当场说“我不关心你们三年后赚多少钱但我关心你们今天能不能帮我看出这家公司的技术短板——这个 demo 做到了。”4.7 场景七跨部门协作——用 demo 统一语言市场部说“用户想要个性化推荐”技术部说“推荐算法需要 3 个月”产品部说“先上个简单版本”。三方争执不下时我们用 demo 打破僵局。做一个极简 demo前端展示 10 个商品卡片后端逻辑只有两行if user.is_vip: return top_10_vip_items() else: return top_10_hot_items()配置开关VIP 用户列表存在内存里随时增删市场部看到“VIP 用户看到的是热销榜普通用户看到的是新品榜”立刻明白“个性化”不等于“AI 推荐”技术部看到这个逻辑 2 小时就能上线同意先用规则引擎过渡产品部基于 demo 数据VIP 用户点击率高 22%决定优先开发 VIP 权益体系。一个 demo让三个部门从“我要什么”转向“我们共同验证什么”。5. 常见问题与独家避坑指南那些没人告诉你的 demo 真相5.1 “demo 做得越漂亮越容易失败”——视觉陷阱的破解法很多团队花 80% 时间美化 demo 界面动效、渐变、品牌色、响应式适配……结果演示时一个按钮点击没反应全场尴尬。真相是demo 的视觉完成度和可信度成反比。用户看到精致 UI会默认“这已经是成品”对任何瑕疵容忍度为零而看到简陋界面反而会说“哦这是 demo我知道还在调试”。我们的破解法是“丑得有道理”禁用 CSS 框架不用 Bootstrap、Tailwind手写 20 行 CSS只保证文字可读、按钮可点、布局不重叠。字体统一用系统默认Windows 用 Segoe UImacOS 用 San FranciscoLinux 用 Noto Sans不加载任何 Web Font。图片用 base64 占位符img srcdata:image/svgxml,%3Csvg xmlnshttp://www.w3.org/2000/svg width200 height150 viewBox0 0 200 150%3E%3Crect width100%25 height100%25 fill%23eee/%3E%3Ctext x50%25 y50%25 dominant-baselinemiddle text-anchormiddle font-size12 fill%23999%3EImage Placeholder%3C/text%3E%3C/svg%3E避免图片加载失败导致布局崩塌。实测数据采用此法的 demo客户现场演示成功率从 73% 提升至 98%。因为大家关注点回到了“功能是否有效”而不是“按钮圆角是不是 8px”。5.2 “demo 不能上线”——但为什么我们坚持让它短暂上线很多团队认为 demo 就是本地运行绝不碰服务器。但我们有个反直觉实践所有 demo 必须部署到公网可访问地址且生命周期严格限定为 72 小时。原因有三暴露真实网络问题本地 localhost 永远不会遇到 DNS 解析失败、HTTPS 证书链不全、CDN 缓存污染等问题。去年一个支付 demo在本地一切正常部署到阿里云 ECS 后发现支付宝回调地址被防火墙拦截若不上线永远发现不了。验证第三方集成微信 JS-SDK、高德地图 API、短信平台等很多限制“只允许备案域名调用”。本地开发时用代理能绕过但 demo 必须直面真实限制。建立心理契约当 demo 有真实 URL如https://demo-pay.yourcompany.com团队会天然重视其稳定性不会写“反正只跑一天”的烂代码。操作规范使用 Lets Encrypt 免费证书配合 acme.sh 自动续期Nginx 配置location / { return 410; }72 小时后自动返回 410 Gone所有日志自动归档到 S3到期后自动删除这个做法看似麻烦却让我们规避了 92% 的“上线即崩溃”问题。5.3 “demo 代码要不要进主干”——Git 分支策略的血泪教训关于 demo 代码是否合并我们经历过三次重大教训第一次把 demo 代码合并进develop分支结果某次紧急 hotfix 误删了 demo 的 mock 接口导致客户演示失败。第二次新建demo-*分支但未设置保护规则实习生误 merge 到main引入了未审计的第三方库。第三次完全隔离demo 代码放在独立仓库但 CI/CD 流水线复用生产配置导致 demo 构建时尝试连接生产数据库。现在的铁律是demo 代码永不进入任何长期分支但必须有独立 CI 流水线。具体操作Git 仓库结构yourproject/主干 yourproject-demo/独立 demo 仓库CI 配置demo 仓库的.gitlab-ci.yml明确禁止访问PRODUCTION_*环境变量所有外部服务用mock-前缀如mock-db、mock-sms部署脚本deploy-demo.sh中硬编码DEMO_EXPIRE_HOURS72超时自动下线这套机制下demo 既是独立实体又能复用主干的组件库通过npm install yourcompany/core-utilsdemo安装 demo 专用版本安全与复用兼得。5.4 “demo 做完就扔”——如何让 demo 成为知识资产很多 demo 做完就被遗忘其实它是绝佳的知识沉淀载体。我们的做法是每个 demo 自动生成 README.md包含验证目标一句话