微信小程序火车票查询源码解析：云函数与接口适配实战

简介：这份资源是一套基于微信小程序实现的火车票查询系统源码，面向具备小程序基础、希望练习接口调用与页面开发的开发者，也可作为课程设计或二次开发的起点。压缩包共23个文件，约11KB，以js逻辑脚本、json配置文件、wxss样式表和wxml页面结构为主，另附一份说明文档，覆盖应用入口、页面配置、请求封装与工具函数等模块，目录划分清晰，便于按功能定位代码。资源中已封装好接口请求逻辑，包含首页查询、车次列表与座位信息等页面雏形，读者可在此基础上替换接口、调整字段或扩展订单、用户中心等功能。目前已有1643人学习下载，适合想快速理解小程序请求流程、页面组织方式与数据渲染思路的入门到中级开发者参考借鉴。

1. 从一次抢票失败说起：这个火车票查询小程序到底能干什么

去年国庆前，A同学在群里吐槽：守着 12306 刷了三天，票没抢到，流量倒是耗了两个 G。我问他为什么不自己写个查询工具定时轮询，他一脸茫然——不是不想，是不知道从哪下手。其实这类需求特别适合用微信小程序来做：不用装 App，打开即用，还能把查询逻辑封装成云函数，手机锁屏也能跑。我手上这份「微信小程序-火车票查询」资源包，就是一套完整的可运行源码，覆盖了车次查询、余票展示、站点选择、日期切换这几个核心模块，前端用原生小程序框架，后端走云开发或自建接口都行。它解决的不是「帮你抢票」这种玄学问题，而是让你拥有一个随时能查、能改、能扩展的查询入口。适合谁？一是想练手小程序全栈的开发者，二是需要把车票查询嵌进自己业务系统的团队，三是单纯想搞明白「查询接口到底怎么调」的技术好奇者。下面我按实际拆包和复现的顺序，把这份资源讲透。

2. 拆开资源包：目录结构、技术栈与接口选型逻辑

2.1 目录结构里藏着作者的设计意图

拿到资源包先别急着跑，花五分钟看目录，能省后面两小时的瞎折腾。这份源码的根目录大致长这样：

train-ticket-miniprogram/ ├── miniprogram/ # 小程序前端主体 │ ├── pages/ │ │ ├── index/ # 查询首页：出发站、到达站、日期 │ │ ├── result/ # 车次列表与余票展示 │ │ └── detail/ # 车次详情：经停站、历时 │ ├── components/ │ │ └── station-picker/ # 站点选择器组件 │ ├── utils/ │ │ ├── request.js # 统一请求封装 │ │ └── date.js # 日期格式化与偏移 │ └── app.js ├── cloudfunctions/ # 云函数目录（若走云开发） │ └── queryTrain/ │ └── index.js # 核心查询逻辑 ├── project.config.json └── README.md

pages下三个页面对应查询流程的三个阶段，components里的站点选择器是独立复用的，utils/request.js把请求拦截、错误码处理、loading 状态都包了一层。这种结构不是随便摆的——它意味着你可以只替换cloudfunctions/queryTrain/index.js里的数据源，前端一行不用改就能切换接口。常见做法是先把request.js的 baseURL 抽成配置项，我一般会在app.js的globalData里放一个env字段，方便切测试和生产。

2.2 技术栈选型：为什么是原生小程序 + 云函数

这份资源没有用 uni-app 或 Taro 这类跨端框架，而是原生小程序语法加云开发。原因很直接：火车票查询的核心是「请求-渲染」链路，不涉及复杂交互，原生框架的setData性能足够，且云函数能天然解决接口鉴权和跨域问题。如果你打算把查询能力开放给外部系统，也可以把云函数换成自建 Node 服务，前端只需改request.js里的域名。

注意：资源包里没有绑定任何具体接口供应商，queryTrain/index.js里留的是一个requestTrainAPI的抽象方法，你需要自己填 endpoint 和 key。这是好事——避免了你拿到手发现接口已失效的尴尬。

2.3 接口适配层的三个关键参数

打开cloudfunctions/queryTrain/index.js，核心逻辑集中在一个函数里。它接收前端传来的fromStation、toStation、trainDate三个参数，然后组装请求。这里有个容易翻车的点：站点名要用车站编码而不是中文名。资源包里内置了一份station_code.json映射表，但只覆盖了主要城市。如果你查的是小站，得自己补全。

// cloudfunctions/queryTrain/index.js 核心片段 const stationMap = require('./station_code.json'); exports.main = async (event, context) => { const { fromStation, toStation, trainDate } = event; // 参数校验：站点必须存在于映射表 const fromCode = stationMap[fromStation]; const toCode = stationMap[toStation]; if (!fromCode || !toCode) { return { code: 400, msg: '站点编码未收录，请补充 station_code.json' }; } // 日期格式校验：必须为 YYYY-MM-DD if (!/^\d{4}-\d{2}-\d{2}$/.test(trainDate)) { return { code: 400, msg: '日期格式错误' }; } // 调用抽象接口层，实际 endpoint 需自行配置 const result = await requestTrainAPI({ from: fromCode, to: toCode, date: trainDate }); return { code: 200, data: result }; };

这段代码的逻辑说明：先做入参校验，避免无效请求打到第三方接口浪费配额；stationMap是本地映射，减少一次网络查询；requestTrainAPI是抽象方法，你需要在同目录下新建api.js实现它。参数方面，trainDate必须精确到天，不支持「明天」「后天」这种自然语言，前端date.js里已经做了转换。我一般会把station_code.json换成自己的全量映射，来源可以是公开的车站编码表，注意别用带版权声明的数据。

2.4 前端请求封装与 loading 状态处理

utils/request.js里封装了wx.request的 Promise 版本，并统一处理了超时和错误提示。资源包默认超时设的是 5000ms，这个值在弱网环境下偏短，建议改成 8000ms。另外它用了一个pendingCount变量来管理 loading 的显示与隐藏，避免多个并发请求导致 loading 闪烁。

// utils/request.js 关键片段 let pendingCount = 0; function request(options) { pendingCount++; wx.showLoading({ title: '查询中', mask: true }); return new Promise((resolve, reject) => { wx.request({ ...options, timeout: 8000, // 原为 5000，弱网建议调大 success: (res) => { if (res.statusCode === 200 && res.data.code === 200) { resolve(res.data.data); } else { reject(new Error(res.data.msg || '查询失败')); } }, fail: (err) => reject(err), complete: () => { pendingCount--; if (pendingCount === 0) { wx.hideLoading(); } } }); }); }

逻辑说明：pendingCount是计数器，每发起一个请求加一，完成时减一，只有归零才隐藏 loading。参数上，mask: true防止用户重复点击查询按钮。这里有个细节——complete里减计数，而不是success或fail，保证异常路径也能正确关闭 loading。如果你要加请求重试，建议在fail里判断错误类型，网络超时才重试，业务错误直接抛给页面。

3. 从零跑通查询链路：环境配置、云函数部署与页面联调

3.1 开发环境准备与项目导入

先把微信开发者工具更新到较新版本，老版本对云函数的调试支持不完整。导入项目时选择资源包根目录，AppID 填你自己的测试号或正式号。如果你没有 AppID，可以用测试号，但云函数功能会受限——这是第一个坑，测试号无法使用云开发。所以要么注册一个个人小程序账号，要么把后端改成自建服务。

导入后，开发者工具会提示「当前项目使用了云开发」，点确认并开通云环境。环境 ID 会生成一串类似train-query-xxx的字符串，把它填到app.js的globalData.cloudEnv里。这一步不做，后面云函数调用会直接报env not found。

// app.js 中配置云环境 App({ globalData: { cloudEnv: 'train-query-xxx', // 替换为你的环境 ID userInfo: null }, onLaunch() { if (!wx.cloud) { console.error('请使用 2.2.3 以上基础库'); return; } wx.cloud.init({ env: this.globalData.cloudEnv, traceUser: true }); } });

参数说明：traceUser设为 true 会在云函数日志里记录用户访问，方便排查问题，但会略微增加日志量。如果你在意隐私，可以设为 false。cloudEnv必须与云开发控制台里的环境 ID 完全一致，大小写敏感。

3.2 云函数部署与依赖安装

在开发者工具左侧文件树里找到cloudfunctions/queryTrain，右键选择「上传并部署：云端安装依赖」。这一步会把你本地的index.js和package.json一起打包上传。资源包的package.json里只声明了一个axios依赖，用于发起 HTTP 请求。如果你用 Node 自带的https模块，可以删掉这个依赖，减小云函数包体积。

部署完成后，在云开发控制台的「云函数」列表里能看到queryTrain，点进去可以看日志和测试。测试时传入如下参数：

{ "fromStation": "北京", "toStation": "上海", "trainDate": "2025-06-01" }

如果返回站点编码未收录，说明station_code.json里没有「北京」或「上海」的映射。打开这个文件检查，正常应该长这样：

{ "北京": "BJP", "上海": "SHH", "广州": "GZQ", "深圳": "SZQ" }

注意：不同数据源的编码体系可能不同，有的用三字码，有的用四字码。资源包默认是三字码，如果你换的接口用四字码，得整体替换映射表。我一般会写个脚本把两种编码都存进去，用的时候按接口要求取。

3.3 前端页面联调与数据绑定

云函数调通后，回到pages/index页面，点击查询按钮应该能触发wx.cloud.callFunction。资源包里index.js的查询逻辑如下：

// pages/index/index.js 查询触发 async onQuery() { const { fromStation, toStation, trainDate } = this.data; if (!fromStation || !toStation || !trainDate) { wx.showToast({ title: '请填写完整', icon: 'none' }); return; } try { const res = await wx.cloud.callFunction({ name: 'queryTrain', data: { fromStation, toStation, trainDate } }); if (res.result.code === 200) { // 跳转结果页并传递数据 wx.navigateTo({ url: `/pages/result/result?data=${encodeURIComponent(JSON.stringify(res.result.data))}` }); } else { wx.showToast({ title: res.result.msg, icon: 'none' }); } } catch (err) { console.error('云函数调用失败', err); wx.showToast({ title: '网络异常', icon: 'none' }); } }

逻辑说明：先做本地非空校验，减少无效云函数调用；callFunction返回的res.result才是云函数return的内容；结果页通过 URL 参数接收数据，这里用了encodeURIComponent防止特殊字符截断。参数上，name必须与云函数目录名一致，data里的字段名要与云函数event解构的字段名匹配。

结果页pages/result拿到数据后，用wx:for渲染车次列表。资源包里的列表项展示了车次号、出发到达时间、历时、二等座余票。如果你要加一等座或商务座，在result.wxml里加一列就行，数据字段名参考接口返回的原始结构。

3.4 站点选择器组件的复用与数据源

components/station-picker是一个底部弹窗组件，支持搜索和字母索引。它的数据源是station_code.json的 key 集合，按拼音首字母分组。资源包里已经写好了分组逻辑，但只覆盖了约 50 个主要城市。如果你要支持全国车站，需要自己补全映射表，然后重新生成分组数据。

// components/station-picker/index.js 分组逻辑 const stationMap = require('../../utils/station_code.json'); const pinyin = require('../../utils/pinyin.js'); // 简易拼音首字母库 Component({ data: { groups: [] }, attached() { const groups = {}; Object.keys(stationMap).forEach(name => { const first = pinyin.getFirstLetter(name); // 取首字母 if (!groups[first]) groups[first] = []; groups[first].push(name); }); // 转为数组并排序 const sorted = Object.keys(groups).sort().map(letter => ({ letter, stations: groups[letter].sort() })); this.setData({ groups: sorted }); } });

参数说明：pinyin.js是一个轻量库，只取首字母，不处理多音字。如果你的站点名有多音字（比如「重庆」的「重」），需要手动维护一个例外表。常见做法是在station_code.json里直接存一个pinyin字段，避免运行时计算。这个组件可以独立抽出来用在其他需要选站点的页面，只要传入station_code.json的路径即可。

4. 避坑与排查：接口、编码、日期的五个血泪教训

4.1 现象：云函数返回 400，提示「站点编码未收录」

原因：station_code.json只覆盖了主要城市，小站或新站没有映射。另外，有些接口要求用车站全称而非城市名，比如「北京南」和「北京」是两个不同编码。

解决：先确认你用的数据源要求的是城市名还是站名。如果是站名，把映射表的 key 改成具体站名。我一般会写个脚本从公开的车站列表生成映射，注意别用带版权声明的数据。补全后重新上传云函数。

4.2 现象：查询结果为空，但接口明明有票

原因：日期格式不对。资源包要求YYYY-MM-DD，但有些接口要求YYYYMMDD或带时间戳。另外，时区问题也会导致查不到——云函数默认 UTC 时间，如果你传的是本地日期，可能差一天。

解决：在云函数里统一做日期格式化，用new Date(trainDate)转成时间戳再按接口要求输出。如果接口要求当天日期，用new Date().toLocaleDateString('zh-CN')生成。注意云函数的时区可以在环境变量里设TZ=Asia/Shanghai。

4.3 现象：前端 loading 一直转，不消失

原因：pendingCount计数没有归零。常见于请求被中断或wx.request的complete没触发。另外，如果云函数调用超时，wx.cloud.callFunction的fail回调可能不执行。

解决：在request.js里加一个兜底定时器，超过 10 秒强制隐藏 loading 并重置计数。代码片段：

// 兜底：10 秒后强制重置 const timer = setTimeout(() => { pendingCount = 0; wx.hideLoading(); }, 10000); // 在 complete 里 clearTimeout(timer)

参数说明：10 秒是经验值，如果你的接口平均响应超过 8 秒，调到 15 秒。这个兜底逻辑不影响正常流程，只在异常时生效。

4.4 现象：站点选择器搜索「西安」搜不到

原因：拼音首字母库把「西安」的首字母算成了「X」，但实际应该按「Xi'an」算「X」没错，问题出在搜索逻辑只匹配了首字母，没有匹配全拼。资源包的搜索框只做了indexOf匹配中文名，没做拼音匹配。

解决：在搜索逻辑里同时匹配中文名和拼音全拼。如果你不想引入完整拼音库，可以在station_code.json里给每个站点加一个pinyin字段，搜索时遍历这个字段。我一般会预生成这个字段，避免运行时计算。

4.5 现象：云函数部署成功但调用报「permission denied」

原因：云函数的权限配置没开。默认情况下，云函数只允许同环境的小程序调用，如果你在测试号里调正式环境的云函数，会被拒绝。另外，云函数的config.json里如果设了permissions限制，也会导致调用失败。

解决：在云开发控制台找到对应云函数，检查「权限设置」是否为「所有用户可调用」或「仅创建者可调用」。如果是自建服务，检查小程序的request合法域名列表是否包含你的接口域名。注意：合法域名必须备案且支持 HTTPS，这是硬性要求。

5. 进阶：把查询结果缓存到本地，减少重复请求

跑通基础查询后，你会发现同一个日期、同一对站点，短时间内重复查询会浪费接口配额。我一般会加一层本地缓存，用wx.setStorageSync存查询结果，设置 5 分钟过期。这样用户来回切换页面时不会重复打接口。

// utils/cache.js 简易缓存封装 const CACHE_PREFIX = 'train_query_'; const EXPIRE = 5 * 60 * 1000; // 5 分钟 function getCache(key) { const fullKey = CACHE_PREFIX + key; const cached = wx.getStorageSync(fullKey); if (cached && Date.now() - cached.time < EXPIRE) { return cached.data; } return null; } function setCache(key, data) { const fullKey = CACHE_PREFIX + key; wx.setStorageSync(fullKey, { time: Date.now(), data }); } module.exports = { getCache, setCache };

逻辑说明：缓存 key 由出发站、到达站、日期拼接而成，保证唯一性。过期时间设 5 分钟，因为余票变化快，太长会导致数据不准。参数上，EXPIRE可以根据你的接口配额调整，配额紧张就设 10 分钟，但要在页面上提示「数据可能有延迟」。

在index.js的查询逻辑里，先查缓存，命中就直接跳结果页，不调云函数：

const cacheKey = `${fromStation}_${toStation}_${trainDate}`; const cached = getCache(cacheKey); if (cached) { wx.navigateTo({ url: `/pages/result/result?data=${encodeURIComponent(JSON.stringify(cached))}` }); return; } // 未命中，走云函数查询，成功后 setCache(cacheKey, res.result.data)

另一个进阶方向是加定时刷新。云函数支持定时触发器，你可以配一个每 10 分钟跑一次的定时任务，把热门线路的余票拉到云数据库，前端直接读数据库。这样查询速度更快，也不受第三方接口限流影响。资源包里没有预置这个逻辑，但cloudfunctions目录下留了config.json的触发器配置模板，取消注释就能用。

从那以后我每次做查询类小程序，都会先把缓存层加上再联调，否则接口配额跑得比预期快得多。希望帮到你。

本文还有配套的精品资源，点击获取