上周我把 atest 升级到了 v0.0.19一开始没当回事毕竟 0.0.x 版本在我眼里就是“修修补补”的代名词。结果用下来发现这个版本把数据库连接和智能 Mock 彻底打通了我的接口联调方式直接被改变。如果你也在做前后端分离开发或者经常为了联调环境准备一大摞假数据那你应该知道这有多痛苦。这篇就把新版 atest 的数据库接入、结构同步、智能 Mock 生成、前后端并行协作这些核心链路完整过一遍中间包括我实际操作过的步骤、踩过的坑以及为什么我最终觉得这套组合能解决根本问题的原因。1. 这次更新解决了什么数据库和 Mock 为什么能凑一对1.1 说一个几乎所有联调场景都逃不掉的痛点真实业务开发里最耗时间的往往不是接口逻辑本身而是“让接口有数据可以返回”。前端要看列表页你就得造一批像样的列表数据后端要对账你得准备订单、金额、用户状态这些关联数据测试要模拟异常场景你又得造各种边界条件。以前我的做法是维护一个巨大的 JSON 文件里面手写所有字段和值写多了就会漏漏了前端一渲染就报 undefined然后又是一轮“前端找后端、后端查代码、最后发现是 Mock 数据少了字段”的拉锯战。这种问题不是靠“认真一点”就能解决的。手写数据天然和表结构脱节字段一多就失控。更麻烦的是当数据库表结构改了比如某个字段从 int 改成 string或者加了一个非空字段手写 Mock 文件不会自动跟着变。最典型的一次我们前端排查了半天为什么列表页老是显示不出新字段最后发现是 Mock 文件里根本没加这个字段而真实接口其实早就返回了。这个时间损耗完全是可以避免的。1.2 数据库连接先行的原因我最开始看到 atest v0.0.19 的更新列表里有“数据库”和“智能 Mock”两个关键词时以为是两个独立功能。真正用下来才明白它们是一条链路数据库先解决“数据来源”和“结构定义”智能 Mock 解决“基于什么生成数据”。顺序上先连数据库、再生成 Mock这个设计是对的。为什么这么说因为 Mock 数据做得再花哨如果字段名和真实表结构对不上前端接上之后照样报错。而一旦把表结构作为 Mock 的事实来源所有字段名、字段类型、是否可空、主键外键、枚举约束全都从真实库里拿生成结果天然就不会偏离业务。换句话说这个版本不是简单加了个数据库客户端也不是把随机数生成器换了个名字而是建立了一个“以数据库结构为准”的数据生产链路。还有一个隐性问题被顺手解决了Mock 环境和真实环境的一致性。以前数据库字段改了手动 Mock 没改两套东西越漂越远。现在只要重新同步一次结构Mock 就会跟着变不需要人肉去核对。对我来说这个改变比多几个生成模板更重要。1.3 v0.0.19 更新拆解不是单纯加功能从版本号就能看出来这项目还在快速迭代阶段0.0.x 的更新幅度已经算很大了。这次的核心是把“结构定义—数据生成—接口模拟”三个环节串成一条完整的自动化链路。在这个版本之前你可能要做三件事写表结构、写 Mock 数据、写接口模拟规则。现在可以简化为连接数据库、同步结构、按需生成接口。三个阶段都围绕同一个数据源整个流程自然就顺了。但也要提醒一句版本迭代快意味着升级时配置格式可能变化。如果你是从更早版本升上来的建议先看一下配置样例别把新功能的 YAML 直接照搬旧版否则容易在启动时被格式校验卡住。后面我会把新版配置的写法讲清楚。2. 数据库接入与结构同步实操2.1 支持范围与前置准备数据库这边常见的 MySQL、PostgreSQL、SQLite 我都试过基本都支持。我实际主力用的是 MySQL 8.0SQLite 则用来做离线验证。连接之前有几个前置条件要先确认数据库服务要能从工具所在机器访问到网络不通说什么都没用。账号要有读取表结构信息的权限一般 SELECT 权限是底线。强烈建议用只读账号去配置不要拿生产超管账号来连 Mock 工具这属于最基本的自我保护。很多人在这一步就翻车是因为权限不够。工具要读 information_schema 或者对应的系统表如果账号只能查业务表但没权限看元数据同步时就会报错或者只同步到部分表。2.2 连接配置每一步怎么选atest 的连接配置我建议放在一个独立的 YAML 文件里方便团队共享。配置大概长这样database: driver: mysql dsn: root:mypasstcp(127.0.0.1:3306)/shop_demo?charsetutf8mb4parseTimeTruelocLocal pool: max_open: 5 max_idle: 2 timeout: 3s几个参数一个个说。driver 就是数据库类型填错直接连不上。dsn 是连接串核心几个点charsetutf8mb4 一定要带否则中文乱码parseTimeTrue 在 MySQL 驱动里保证时间字段能被正确解析locLocal 让时间按本地时区处理。pool 这块很多人会忽略。工具只是做结构同步和数据生成不是跑业务请求连接数不需要很大。max_open 我建议 3 到 10 就够了别一上来就配 50。有一次我图省事把连接池调到很大联调节奏一快开发库直接报 too many connections把同事的查询也影响了。开发工具保持克制很重要。2.3 结构同步会做什么连接成功后第一次同步会把整库的结构信息拉下来具体包括所有业务表清单以及每张表的字段名、字段类型、是否可空、默认值。主键、唯一索引、普通索引信息。外键关系这点对后续关联数据生成很关键。这些信息会生成一份本地结构快照相当于数据库元数据的缓存文件。之后再跑同步命令atest 会跟快照做 diff告诉你哪些表新增了、哪些字段改了、哪些索引被删掉了。你还可以手工编辑这份快照把不需要参与 Mock 的表或字段过滤掉。这种做法的价值怎么强调都不算过分。你不需要再拿着 SQL 和字段清单反复核对也不用担心某张表加了个非空字段后 Mock 数据生成失败。同步一次所有生成环节就都拿到了“什么字段必须给、什么字段可以空”的信息。工作流从“人肉同步”变成了“结构即事实”。2.4 结构不同步的手动处理有一种情况比较特殊数据库还没交付但接口要先写起来。这时候你连不上真实库也可以通过 SQL 文件先建一个虚拟 schema让 atest 基于这个 schema 先工作。配置上把数据源指向一个 dump 文件就行相当于离线模式。这对早期并行开发非常有用。只要 DBA 或者后端把建表语句发过来哪怕数据库还没搭Mock 接口也能先按照表结构生成出来前端先跑着后端再慢慢做真实实现。等到数据库真正可用再切回在线同步所有 Mock 数据自动按最新结构重新生成不需要中间返工。3. 智能 Mock 的核心玩法3.1 传统 Mock 和智能 Mock 的差别传统做法是写死一段 JSON或者用随机数生成器填值。前者的问题是不够灵活后端接口一变就得改文件后者的问题更隐蔽——类型可能对但业务语义完全不搭。一个字段叫duration传统随机数可能生成负数一个字段叫status取值范围可能被填成 9999前端一看就懵。智能 Mock 的差别在于它会先“读”字段信息再做决策。字段名叫email生成的就是邮箱格式字段类型是decimal且长度是 10,2生成的就是两位小数字段有外键引用那生成的值一定来自被引用表里的已有数据不会出现 id 对不上号的情况。这套逻辑实际上是把“对业务的理解”固化成了规则引擎。3.2 内置规则为什么不等于“随机数”我拆解一下 atest 内置规则大概会做的判断这样你能理解它是怎么做到“像真的”字符串类型字段根据字段名推断语义。比如包含 name、address、city、title 这些词会生成中文或英文的人名、地址、城市、标题而不是asdf123这种乱码。整型和浮点型字段自动判断是序号、金额、数量还是百分比。金额不会出现负数百分比不会超过 100。时间类型字段生成最近一段时间内的合法时间戳而不是把年份填成 1900。布尔和枚举字段布尔只在 true/false 之间取枚举只从约束值里取。你会发现这些规则其实就是平时手写 Mock 数据时的惯性逻辑。工具把这些经验沉淀下来你就不用每次重写一遍。3.3 规则自定义与脚本扩展内置规则只能覆盖常见场景遇到业务特有字段还要自己定义。atest 支持在配置里按表按字段指定规则举例如下mock: tables: - name: t_user rules: - field: mobile type: phone - field: balance type: decimal min: 0 max: 200000 precision: 2 - field: created_at type: datetime range: 2024-01-01 00:00:00 ~ 2025-01-01 00:00:00这个配置的意思就是t_user 表的 mobile 用手机号规则生成balance 是 0 到 20 万之间保留两位小数的数值created_at 在指定时间区间内生成。如果配置规则还不够可以直接写一段 JavaScript 脚本在每一条记录生成前后做校验和修正。这个能力在面对复杂业务字段时很有用特别是那些需要多字段联动计算的场景。比如订单表里如果status2表示已支付那pay_time就不该为空脚本可以用来保证这种逻辑一致性。3.4 一个容易忽略的关键点字段唯一性唯一字段的处理是 Mock 工具最容易翻车的地方。有些字段在现实里必须是唯一的比如订单号、手机号、身份证件号。如果你只是按规则随机生成数据量一大就容易撞车。直到这个版本我注意到唯一索引字段的生成逻辑被单独处理了生成过程中会维护一个集合每生成一个值就做去重检查如果撞了会重新生成。但有一点要提醒如果一个唯一字段的候选空间很小比如长度只有 1 的字符串那生成几万条记录时再怎么做去重都会耗尽。遇到这种情况你需要自己把规则参数调大或者通过脚本加随机前缀否则数据量一大还是会重复。这个不是工具问题是生成空间本身的物理限制。4. 线上场景全流程从数据表到可调用接口4.1 准备模拟业务表我拿一个最典型的电商订单场景走一遍完整流程。先准备一张订单表结构设计得稍微有代表性一点包含唯一键、外键、金额、状态、时间等多个类型CREATE TABLE t_order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL, user_id bigint NOT NULL, amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0, pay_time datetime DEFAULT NULL, remark varchar(255) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) );这张表有普通字段、金额字段、状态字段、可空时间字段、唯一键已经能覆盖大部分 Mock 生成会遇到的情况。4.2 同步数据库并生成接口数据库准备好后执行同步命令。命令行操作大致是这样具体命令名以你当前版本为准atest db sync --config atest.yaml同步完成之后atest 已经知道这张表有什么字段、哪些字段必填、哪些不能重复。接着生成接口atest mock gen table --name t_order这一步会把 t_order 变成一套可以直接访问的接口路由而不只是生成一份静态数据。4.3 接口路由与返回结构配置生成完接口后还需要在配置里定义路由的访问方式。我用的配置大概长这样mock: apis: - path: /api/orders method: GET handler: table table: t_order page_size: 20 total: 356 - path: /api/orders/:id method: GET handler: table table: t_order where: - { id: $id }handler 字段设为 table表示这个接口以“表模式”工作自动按表结构返回数据。列表接口会自动分页详情接口会自动按主键过滤。total 可以手动指定一个值这样前端分页组件能展示出和真实业务相近的总条数。运行起来之后可以直接用 curl 验证curl http://127.0.0.1:8080/api/orders?page1size10返回的 JSON 里字段名、字段类型、数据格式都会严格按照 t_order 表结构来。哪怕这张表之后加了字段只要重新同步一次接口返回也会自动带出新字段不用手工去改任何 Mock 文件。4.4 前端如何直接切换到 Mock 数据源这里分享一个我建议团队采用的协作方式不依赖某个具体工具。在前端的公共环境配置里放一个开关{ mock: true, apiBaseUrl: http://127.0.0.1:8080 }mock为 true 时前端所有接口都请求 atest 的 Mock 服务为 false 时请求真实后端地址。切换只需要改一个配置项前端开发完全不需要等后端接口就绪。这样做的意义在于前后端可以真正做到并行开发。前端基于表结构生成的 Mock 数据先开发页面逻辑后端基于同一张表专注实现业务接口两边最后联调时再切换到真实数据源。因为 Mock 数据是从真实表结构生成的字段名和类型天然一致联调时真正要处理的只剩业务逻辑差异不会出现“前端用的字段后端根本没返回”这种结构性问题。5. 常见问题与排查技巧实录5.1 数据库连接失败先看这几处连接失败是最常见的启动问题我遇到过的原因按概率排序大概是这样现象可能原因排查方法报错无法解析 dsndsn 里密码含特殊字符没转义使用 URL 编码处理特殊字符比如 写成 %40一直卡在连接中网络不通或端口被封先用 mysql 命令行或客户端测试是否能连上确认网络链路权限报错账号只有业务表权限没有元数据权限改用有 information_schema 读取权限的账号连接被拒数据库连接数已经占满检查数据库 max_connections 并适当调小工具连接池我自己的经验是先用数据库自带客户端验证 dsn 字符串本身能连通再放到 atest 里排错。如果客户端都连不上那问题大概率不在工具而在网络或账号权限。5.2 同步出来的结构和预期不一致有时候同步完成后你会发现某个字段的类型和数据库里对不上比如数据库是 varchar(64)同步后成了 text。这种一般是驱动版本太旧类型映射表不完整导致的。解决办法是先升级数据库驱动到新版本重新同步。如果驱动升级后还是不对可以在结构快照里手动覆盖字段类型。注意别直接改数据库那是更危险的路径。5.3 Mock 数据生成结果不符合预期生成结果不像真实数据大多是规则没命中。常见的几种情况字段名比较特殊内置规则没识别出语义生成了一串乱码。处理方式是显式配置字段规则。关联字段没生成对应记录外键引用的表要先于子表生成数据顺序不能反。中文乱码检查 dsn 里有没有 charsetutf8mb4以及生成的配置文件本身是不是 UTF-8 编码。如果你觉得生成的某一列数据太规整、不像真实业务也可以给这个字段单独加一点随机偏移让数据分布更自然。5.4 并发调接口出现重复和卡顿多个前端同事同时调 Mock 接口可能会出现两种情况一是唯一字段重复二是接口响应变慢。唯一字段重复的原因要看这个字段的生成是否被正确识别为唯一键。如果库里有唯一索引但工具没有同步到是不会有去重逻辑的。先确认结构快照里有没有 uk_order_no 这类唯一键信息。响应变慢大多是全量重新生成导致的。数据量大时每次请求都全量生成一次必然拖慢速度。正确的做法是开启增量生成模式或者提前批量生成好一批数据让请求只做查询不做生成。6. 我实际用了两周后的几点体会6.1 最大的变化不是少了手写 JSON用了大概两周最大的感受是省下的时间其实不是“少写了几个 JSON 文件”而是少了一整类“结构不一致”的排查工作。以前前端报字段不对我要先去数据库看表结构再回 Mock 文件里找字段两头核对才能定位问题。现在数据源只有一个出了问题不会往结构对不上这个方向猜问题面一下子小了很多。对个人开发者来说这个改变也许不那么明显毕竟自己给自己造数据怎么都能造但对团队协作来说统一数据源带来的收益是几何级别的。每个成员看到的接口返回结构都从同一张表结构演化而来沟通成本会低很多。6.2 一些后续能继续扩展的方向以这个版本为基础如果继续往前做我认为最值得期待的是差量同步的稳定性、团队级规则配置共享以及更细粒度的敏感字段脱敏。尤其脱敏这一点在联调数据要用到用户信息的时候特别重要真实数字不能直接给测试环境但 Mock 生成的又必须长得像真的。这个平衡如果做好了开发工具就不再只是“方便”而是整个研发流程里不可缺的一个环节。我自己接下来的计划是把这套数据库加智能 Mock 的流程推广到更多项目里同时把团队自定义的 Mock 规则沉淀成公共配置。这样不管新来的同事还是跨团队协作都能立刻用上统一的标准数据不需要每个人重新摸索一遍。实践下来我觉得这方向值得继续投入。