Demo与生产环境差异：FDE必避的“上线翻车”陷阱与自检清单

上周四我蹲在客户现场处理告警，业务群里的运营姑娘甩出一句话：“当初Demo演示的时候不是跑得好好的吗？怎么一上线全是问题？”这句话我相信很多FDE都听过，甚至自己心里也犯过嘀咕。FDE这个岗位，说白了就是要把方案真正落到业务环境里的那批人，日常打交道最多的不是完整产品，而是各种赶工拼出来的Demo。Demo做得好不好看，直接决定客户愿不愿意往下推进。但问题恰恰藏在这里：Demo天生带着“表演人格”，它是为了展示效果而生的，不是为生产环境而生的。一个FDE如果长期在Demo模式下工作，很容易养成一套“能跑就行”的肌肉记忆，等到真正上线那天，平时靠演示场景掩盖起来的雷，一颗接一颗地被引爆。这篇我就结合自己做FDE这几年踩过的坑，把“Demo好看但上线翻车”这件事彻底拆开聊，内容包括Demo与线上环境的本质差异、上线翻车最常见的工程化原因、一次真实的上线事故排查链路，以及我后来固定下来的一套上线前检查清单。

1. Demo和线上环境的差异不是“一点”，是“物种”

1.1 Demo的宿命就是“在受控环境下表演”

Demo是demonstration的缩写，干的就是“演示”这回事。它从诞生那天起就有一个明确目标：在指定时间窗口内，把最有价值的功能以最稳定的姿态展示给观众。为了达成这个目标，做Demo的FDE会不自觉地围绕“展示那一刻”做各种特殊优化。

数据固定成可预期的小数据集，网络默认良好，并发永远假设只有一个人在用，不考虑权限、审计、日志，甚至崩了可以直接重来一遍。这在演示场景下完全合理，毕竟演示的核心诉求是“别出岔子”。但问题在于，很多人把这种Demo模式下的合理性，原封不动地带进了线上环境。

FDE通常负责从业务沟通、技术选型、Demo制作到上线执行的一条龙交付，长期处于“时间紧、任务重、效果还要惊艳”的压力下，写出来的代码带着很强的短命基因。这不是技术能力的问题，而是典型的激励错位：Demo是给观看者打分的，线上是给真实用户打分的，两套评价标准完全不同，开发行为自然就会跑偏。我见过不少代码能力很强的FDE，做Demo是一把好手，可一上线就抓瞎，原因就在这里——不是不会写生产级代码，而是根本没意识到两者的评判体系从一开始就不是一回事。

1.2 环境差异：一次没对齐的“运行环境”就能全盘崩

我在实际项目里见过最容易引发上线事故的，其实是环境差异。Demo通常跑在开发机或者一台临时云主机上，CPU、内存、带宽都是满配，网络也是直连。生产环境往往要考虑成本，虚拟机规格直接减半，网络中间多了网关策略、安全组、CDN缓存层，甚至还有一层WAF过滤。每一个中间层都可能成为新的不确定因素。

举个我自己的例子。之前做一个文件上传功能的Demo，本地上传一张2MB的图片，耗时300毫秒，客户当场觉得满意。Demo现场连的是千兆局域网，传文件几乎秒开。上线后，业务人员在办公室用Wi-Fi，网络一拥堵，一个5MB的文件传半天传不上去，超时提示弹出来，业务群炸了。功能本身没有问题，问题在于Demo阶段从来没有模拟过“最差网络”这个输入条件。

后来我再做类似功能，会刻意在Demo里加一个网络模拟开关，可以手动切换“流畅模式”和“弱网模式”，让客户现场直接感受两种体验。这个细节不仅让演示更有说服力，也能提前暴露出一些上线后必定会出的问题。很多FDE觉得这是多余的工作量，但对比一次线上故障的沟通成本和时间成本，这点投入实在太划算了。

1.3 数据规模：Demo里十条数据，线上可能要面对百万级

Demo里的数据通常是几条到几十条，前端列表秒开，图表动画丝滑，翻页如飞。一旦接上生产数据库，情况就完全变了。一张表里几百万行数据，接口没做分页，前端直接卡死；没有加索引，单次查询超时；没有做缓存，数据库连接池瞬间被打爆。

这个差异最容易被忽视，也最致命。因为Demo的美观度很大程度上就是由数据规模撑起来的。功能逻辑写得再漂亮，一旦数据量上来，没有经过规模验证的代码都会现出原形。我见过一个Demo，演示时订单列表加载得行云流水，上线后客户反馈“进入订单页要转十几秒”。查下来就是接口SQL没有任何分页限制，一次把全表查出来返回给前端，在百万行数据面前，再好的前端也救不回来。

踩过这个坑之后，我养成了一个习惯：在Demo阶段就明确区分“演示数据”和“真实数据”的边界，至少保留替换数据源的能力，不要图省事把数据路径硬编码死。这样在预发环境做一次全量数据验证时，只需要切换数据源配置，就能立刻知道真实数据规模下系统到底表现如何。

2. 上线必炸的工程化细节，我数了一下大概有六类

FDE的工作节奏决定了我们很难像正规研发团队那样走全套需求评审、代码评审、自动化测试流程。但上线失败这件事，其实是可以被归类的。我根据自己的实战经验和大量复盘案例，把最常见的翻车原因归成六类，每一类都对应一个上线必炸的场景。

2.1 第一类：配置与凭据写死在代码里

这个问题太常见了。Demo为了演示方便，把数据库地址、接口地址、API Key直接写在配置文件里，甚至直接写死在代码里。上线前总想着“待会儿再改”，结果一忙起来就彻底忘了。后果有两种：要么连错环境，数据全部错乱；要么生产凭据泄漏，直接变成安全事件。

我处理过一个特别典型的权限问题：客户上线后发现所有用户都能看到内部管理后台菜单。排查后发现，Admin权限判断逻辑里写死了一个管理员ID，这个ID在演示环境里是存在的，但生产环境的用户表里根本没有这个ID。于是权限判断永远走不到“是管理员”的分支，竟然阴差阳错地把后台菜单放了出来。这种问题如果靠人工肉眼去翻代码，很难发现，但只要上线前用环境变量方式把配置整理一遍，基本就能避免。

2.2 第二类：异常处理等于零

Demo的运行前提是“一切正常”。所以几乎所有人在做Demo时都会把异常处理省略掉——不做网络错误提示、不做空数据处理、不做兜底分支。上线后第一位用户输入了非法字符，接口直接500；第三位用户网络闪断，前端白屏；第五位用户上传了一个超大文件，后端内存溢出直接宕机。

可以这么说，线上系统拼的不是谁的功能更炫，而是谁在异常情况下还能保持可用。一个接口能不能在入参不合法时返回友好的提示，一个页面能不能在接口报错时给出重试按钮，这些在Demo里根本看不见，但在线上用户眼里就是“这系统烂透了”的全部理由。我现在的做法是，核心业务请求路径上的异常处理绝对不省略，至少要做到：入参校验、空值兜底、网络超时提示这三个动作。

2.3 第三类：资源管理是一笔糊涂账

数据库连接不关闭、文件流不释放、线程池不设上限、内存缓存无限增长。这在Demo阶段完全发现不了，因为Demo的运行时长通常只有几分钟，再多的资源泄漏也看不出后果。生产环境是7×24小时运行的，一晚上过去，连接数打满，第二天业务一开张系统就罢工。

我见过最离谱的一次：一个Demo服务的数据库连接根本没用连接池，每来一个请求就新建一个连接，请求结束也不关闭。演示时两三个并发，毫无压力。上线后业务量一上来，数据库端的连接数瞬间爆掉，DBA半夜翻日志，最后定位到代码里一行被注释掉的close语句。这个教训让我下定决心，凡是涉及连接、线程、文件的地方，一律用带池化管理的组件，并且为池子设置合理的上限。

2.4 第四类：状态管理全放在本地内存

Demo不需要考虑多实例部署，Session、缓存、临时数据统统放在本地内存，简单直接。上线后如果做了多副本部署或者自动扩容，用户的请求被负载均衡到不同实例，Session在各实例之间不共享，用户就会“莫名其妙掉线”。如果上线架构保持单实例，那就要面对单点故障，服务一旦重启，所有用户状态清零。

更隐蔽的问题出在定时任务上。单实例Demo里的定时任务只在当前进程里跑，多实例部署后，每个实例都会执行一遍，就会造成重复数据。解决思路也不复杂：要么把状态外置到Redis这类统一存储，要么在任务上加分布式锁。核心原则就一句话——任何“只有我自己知道”的状态，都不可能在线上长期安全存在。

2.5 第五类：没有日志和监控

Demo出问题怎么排查？重跑一遍就行。但线上没有“重跑”这个选项。没有访问日志，不知道请求从哪来；没有错误日志，不知道崩溃原因；没有监控看板，连服务是什么时候挂的都不知道。上线事故最怕的不是“挂了”，而是“挂了之后完全查不到线索”。

我之前有个项目，线上接口偶发超时，但频率很低，大概一小时一两次，根本无法复现。因为没有日志，我只能靠猜。后来加了日志和调用链追踪，才发现是某个第三方接口偶发慢调用，把线程池里的线程全部占满，导致其他请求排队超时。没有日志，这种问题排查起来如同大海捞针；有了日志，定位只需十分钟。

2.6 第六类：依赖的外部服务没有降级方案

Demo跑得流畅，通常是因为依赖的服务都很健康。但没有任何团队能保证第三方服务、短信通道、支付接口永远稳定。如果主流程直接强依赖这些外部服务，且没有任何降级手段，外部一抖动，整个业务跟着瘫痪。

比较典型的场景是支付回调。Demo里调的是沙箱环境，响应都是毫秒级，一切顺利。生产环境的回调要真实调用门店系统或者银行接口，对方晚高峰处理能力下降，一个请求可能卡几十秒。如果主流程是同步等待，用户端就一直在转圈，体验极差。正确做法是异步化加超时熔断，让主流程先返回成功，再从回调里更新状态。对关键外部服务，一定要问自己一个问题：如果它现在挂了，我的系统会怎样？回答不出这个问题，就不要上线。

下面这张表把这六类问题的典型特征、触发时机和破坏程度做了个汇总，排查的时候拿它当参考很实用。

3. 一次真实的上线事故：从群消息到根因，我用了两小时

3.1 事故现象的第一个版本

事情背景是我帮一家做线下零售的客户上线扫码点单小程序的后端扩展功能。Demo在演示环境里跑得极其顺利：扫码、选品、加入购物车、提交订单、选择支付方式、支付回调、订单查询，全程动画流畅，客户领导当场点头。正式上线后的第二天，运营在群里反馈：晚间高峰时段，经常有顾客扫码后页面一直转圈，过一会儿提示“系统繁忙”。

刚开始我以为是服务器带宽不够，因为Demo用的是一台4核8G的云主机，生产环境当时也复用了这一台——这本身就是个隐患，但紧迫的排期不允许先拆分。上线时，小程序前端静态资源、接口服务、数据库全在这台机器上，晚高峰CPU和内存双双报警。第一反应是“加配置”，但我很快否定了这个方案，因为加配置只是把问题往后推，根本原因还没找到。

3.2 排查链路：日志、慢查询、依赖调用三层过滤

我先看应用错误日志。结果发现日志里大量出现数据库连接超时的异常，时间集中在晚上7点到9点。这个信息说明连接池不足以支撑高峰期的并发请求，但为什么会打满连接池？带着这个疑问继续往下查。

第二步查数据库慢查询日志。发现订单表的查询频繁触发全表扫描，单次扫描行数达到百万级。原因很清晰：建表时没有针对“门店+订单状态”这个高频查询条件建立联合索引，导致每次查询都要把整张表捞一遍，耗时自然高。数据库查询一慢，连接就被占住不释放，连接池很快就满了，后来的请求全部排队等连接，最终超时。

第三步回到应用日志看异常堆栈，又发现一处同步等待的第三方调用：支付回调时，主流程同步等待外部门店系统的响应。门店系统在晚高峰处理能力下降，一个回调可能卡十几秒，支付线程全部被占死，回调队列越积越长。三个问题叠加，才造成了“高峰时段转圈，然后提示系统繁忙”的用户体验。

3.3 为什么Demo阶段没发现？这才是最值得说的

Demo演示时用的是内部测试商户，支付回调走的是沙箱环境，对方响应在100毫秒内返回，完全不会卡。生产环境的回调要真实调用门店系统，而门店系统在晚高峰的处理能力天然受限。这是典型的“依赖真实化”问题，Demo和线上之间的差距不是代码量，而是调用链路上每个环节的真实性。

同样，演示环境里的数据库表里只有几十条订单数据，全表扫描几十条数据毫秒级完成，索引根本体现不出价值。生产库里几十万条订单再加明细数据，查询效率天差地别。Demo能发现问题才是怪事，因为演示的表里压根就没有“足够多”的数据去触发慢查询。

3.4 修复方案与上线后的验证

按优先级我做了三件事。第一个修复：给订单查询和创建的高频SQL全部加上联合索引，把全表扫描变成索引命中，单次查询时间从800多毫秒压到30毫秒左右。第二个修复：给数据库连接池设置了一个合理的最大连接数，同时把闲置连接回收打开，避免连接被无效占用。第三个修复：支付回调从同步等待改为异步通知，主流程先给用户返回成功结果，门店系统同步完成后再更新订单状态。

修复之后，我挑了一个周五的晚高峰做灰度验证。观察指标包括接口平均响应时间、错误率、连接池使用率。连续观察了两个晚间高峰时段，接口平均响应时间稳定在500毫秒以内，“系统繁忙”的提示再没出现过。复盘这场事故，我对自己说了句实话：这既不是运维的锅，也不是数据库的锅，是FDE在Demo阶段就埋下了三颗雷——没有建立性能基线、没有验证真实调用链路、没有给外部依赖设置超时阈值。如果我在Demo交付当天就坚持做一轮简单的压测和慢查询分析，这三类问题完全可以在演示环境里暴露。

4. 一套能直接抄走的上线前自检清单

经历了上面那次事故之后，我把“上线前自检”这一件事固定成了标准动作，整理成了一套走查清单。这套清单不依赖任何复杂平台工具，就是一个查表，FDE单人就能执行，对团队同样适用。它的初衷不是走形式，而是逼着你在上线前把所有不确定性过一遍。

4.1 配置与环境

• 配置文件里所有硬编码的环境地址，统一改为环境变量或配置中心管理
• 删除演示用账号、测试商户、测试密钥等所有测试凭据
• 确认生产数据库连接串、缓存地址、消息队列地址与线上环境逐一对应
• 确认域名、HTTPS证书、反向代理规则已经正确配置
• 确认权限模型不是“演示管理员通用”，而是按最小权限原则配置

这个阶段的核心目标只有一个：让代码在任意环境都能通过配置切换，避免环境错位造成的连锁问题。不要觉得麻烦，我处理过的最严重事故就是环境地址写错，导致上线后数据写进了测试库，客户对账的时候才发现，数据早已被后续流程覆盖。

4.2 数据与状态

• 确认所有数据库表都有主键，高频查询字段有联合索引
• 确认所有分页查询都带LIMIT，不存在全量返回
• 确认列表查询有「空态、加载态、错误态」三个界面状态
• 确认缓存设计了合理的过期时间与淘汰策略
• 确认Session之外的关键业务状态已经持久化，不依赖单机内存

特别想强调其中一条：一定要用生产数据的规模做一次抽样验证。方法很朴素，把生产库脱敏后导出一个副本，在预发环境跑一遍核心链路，观察平均响应时间是否在可接受区间。只有百万行数据下也能稳定运行，线上才算靠谱。很多人上线前觉得“数据量不会突然变大”，但业务增长的速度往往超出想象，宁可提前验证，不要事后救火。

4.3 异常与容错

• 对文件上传、外部接口调用、支付回调等场景，验证超时重试与幂等逻辑
• 对关键外部服务设计降级策略和熔断阈值，不允许“外部挂了我也挂”
• 确认应用日志打印了请求ID，方便做全链路追踪
• 确认数据库连接池、线程池都有明确的上下限配置
• 做一次“杀进程模拟”：服务被kill之后能否自动拉起，数据是否仍然一致

异常与容错这一块，很多人觉得是“额外工作量”，但恰恰是这些工作决定了系统的下限。Demo演示的是一个系统在晴天下的样子，上线面对的是下暴雨、刮台风、甚至有泥石流的真实世界。没有容错设计，一次第三方秒级抖动就能让整条业务链路瘫痪。

4.4 监控与告警

• 确认接入了基础监控，包括CPU、内存、磁盘、网络四项
• 为接口请求量、错误率、平均响应时间分别配置告警阈值
• 确认有独立的错误日志采集通道，出错后能第一时间通过IM工具通知到人
• 检查监控看板是否可访问，至少能看到最近30分钟的趋势图

一个很扎心的事实：很多系统上线后，FDE自己都不知道它有没有挂，是客户先发现然后在群里@你的。出现这种情况的根本原因就是监控缺位。监控不是给运维用的，是给FDE自己用的。没有监控，你就等于闭着眼睛开一辆不知道时速的车，出事故只是时间问题。

4.5 安全与合规

• 确认所有对外接口都有鉴权，未登录状态不可调用
• 确认密码、密钥、Token不输出到明文日志
• 确认上传文件有类型和大小双重校验
• 确认对外服务走的是HTTPS，不存在明文传输

安全这项经常被FDE忽略，因为Demo阶段根本没有“攻击者”这个概念。可一旦上线，开放的接口就成了靶子。不需要做到等保级别，但最基本的鉴权和敏感信息保护一定要有。我见过一个内部工具上线后没有做任何鉴权，结果被搜索引擎抓到了数据接口，所有业务数据直接暴露在公网，这件事成了我职业生涯里最深刻的教训之一。

这套清单建议直接粘到项目文档里，每次上线前逐项打勾。最重要的是：不要上线当天才拿出来对，而是从Demo开发第一天就要想清楚，其中哪几项会直接影响架构选型。比如如果知道将来要做状态外置，那从一开始就不要把Session存本地；如果知道要做监控，那日志格式从一开始就要统一。检查清单的价值不在上线前那一小时，而在它倒逼你在开发阶段就做出更接近生产环境的技术决策。

5. 让以后的Demo既好看又能上线：三个心态层面上的转变

5.1 对Demo的定义：它是“验证工具”，不是“表演材料”

很多FDE做Demo，目标都写着“让客户觉得厉害”。这不完全错，但如果Demo的终点就是演示成功那一刻，那就永远不会有线上质量。我现在做Demo，把“验证一个不确定的风险”作为第一目标。比如用户是否接受这个交互方式？这套接口在真实数据规模下的响应时间是否成立？第三方依赖是否稳定？演示效果反而排在第二位。

把这个顺序反过来之后，我做的Demo在设计上会有明显的变化。比如我会在Demo里故意留一个“数据量切换”按钮，可以让客户现场从一百条数据切到十万条数据，直观展示性能变化。这比花精力去调一个自适应动画要有价值得多。因为客户看得见的只是表象，而真正决定上线成败的，是那些被表象掩盖的性能指标和边界条件。

5.2 对上线的心态：上线一次，就是一次“承认不确定性”的仪式

刚做FDE的时候，我对上线的理解是“写完代码，部署上去，不出bug就是成功”。现在我的理解变了：上线不是“我写得没问题所以一定能上”，而是“我有足够的信息证明它在真实环境下大概率没问题”。一次靠谱的上线，要做的就是提前把不确定的地方全部找出来，能验证的验证，不能验证的留出降级手段。

这个心态转变，直接改变了我的工作节奏。以前我是上线那天才开始紧张，现在是Demo做完那天就开始紧张。紧张的原因不是不自信，而是脑子里有一张“不确定性清单”：数据库索引验证过了没？外部依赖超时设置了没？日志能不能追踪到完整链路？一旦把清单里的每一项都确认完，上线反而变成了一件平静的事。

5.3 对工作的流程：把“上线评审”前置到Demo阶段

我现在的工作习惯是：在Demo做到八成的时候，就叫上后端、运维或者懂生产环境的人一起过一次技术方案。不用花太久，30分钟足够，核心回答三个问题：

• 这次上线会引入哪些新的外部依赖？
• 哪些接口会被频繁调用，大概的量级是多少？
• 万一挂了，我们的恢复手段是什么？

这三个问题一问完，大部分上线隐患就已经现形了。很多FDE不是不懂技术，而是把技术方案评审放在上线前最后一刻才做，这时候架构已经定死了，改动成本最大。提前在Demo阶段做评审，架构还可以调整，成本是最低的。而且Demo阶段过评审还有一个额外好处：后端和运维能提前看到未来要维护什么，有心理准备，不会在上线时手忙脚乱。

我自己这几年的体会是，FDE这个岗位最大的价值，恰恰就是把Demo到上线中间那段“看着很近，其实很远”的距离走完。而走完这段路的核心能力，不是写得一手漂亮的演示代码，而是具备把演示代码里的花架子掂量清楚、知道哪些部分能安全移植到线上、哪些部分只是障眼法的判断力。回想这几年踩过的坑，最有效的一条经验其实特别朴素：每次做完一个Demo，我都强制自己问一句——如果它明天就被推到生产上，我会最害怕哪一个部分？然后立刻去看那个部分，把最害怕的东西验证掉，或者拆掉。坚持这么做完几轮之后，我再上线的时候就很少收到“为什么Demo可以，线上不行”的消息了。如果你也在做FDE或者类似角色，不妨把这一问加进自己的工作习惯里，它比任何工具都管用。