简介一份仿58同城风格的本地生活小程序前端源码适合正在学习微信小程序开发或需要快速搭建本地信息服务类应用的开发者。资源压缩包共14个文件体积仅487KB11张图片资源配合app.json全局配置、app.js应用逻辑与app.wxss公共样式能快速梳理小程序从启动到页面渲染的基础结构。源码还包含页面目录、工具函数、图片资源和请求模块等常见工程划分覆盖数据绑定、事件处理、路由跳转与网络请求等核心知识点整体目录结构清晰便于学习者按模块阅读。已有497人学习下载既可以作为系统学习微信小程序的实战参考也能拿来当作课设/毕设或商业项目起步模板通过替换数据、接口与样式即可搭建同城信息、租房招聘等场景的可用原型。1. 本地宝仿58同城小程序源码下载前先拆清楚前端要做什么搜“本地宝仿58同城小程序源码下载前端”的人通常不是缺那几 MB 的代码包而是拿到源码后发现跑不起来、页面和真机对不上、接口报错一片红。仿58同城这类分类信息小程序前端核心就三件事城市切换、分类信息流、详情页与发布页。本地宝的形态更像“城市生活服务入口”把招聘、房产、二手、家政、转让这些类目塞进一个小程序首页信息密度比普通商城高一个量级。本文不评价任何一份具体源码的好坏只把做这类前端时最常见的取舍、分页策略、导航栏适配和自测方法讲清楚。新手照着搭能少走弯路五年以上经验的人看参数边界和容错设计也会有可搬的东西。2. 仿58同城小程序前端的选型、目录结构与数据请求层2.1 微信原生小程序还是 uniapp选型差别在哪拿到标题里的“小程序源码前端”第一步先分清它是微信原生小程序还是 uniapp 工程。原生小程序的典型特征是有app.json、pages目录、WXML文件uniapp 工程则是一套src/pagesvue文件编译后才产出小程序代码。判断错了后面所有调试都会在错误的方向上浪费时间。微信原生小程序适合团队长期只做微信端、要深挖微信能力的场景订阅消息、私域分享、实时定位接口、蓝牙等原生能力调用最直接没有跨端框架的编译层干扰。uniapp 适合后面想同时出支付宝小程序、抖音小程序或 App 的场景一套 Vue 代码多端发布但代价是部分微信特性要绕一层 API 兼容层。本地宝和58同城这类信息平台绝大多数流量在微信内我一般建议直接上微信原生理由很简单这类项目的核心页面是信息流和详情页对列表渲染性能、滚动流畅度要求高原生小程序的 setData 虽然限制多但行为最可控。2.1.1 工程结构的骨架和页面路由表先建一个标准的微信小程序前端结构目录划分按“页面 组件 工具 接口”四层来组织pages/ index/ # 首页城市切换 分类宫格 信息流 list/ # 列表页按分类、区域、筛选条件展示 detail/ # 详情页信息内容 联系方式 浏览计数 publish/ # 发布页标题、描述、图片、联系方式 mine/ # 我的发布记录、收藏、足迹 components/ nav-bar/ # 自定义导航栏组件 news-card/ # 信息流卡片组件 empty-view/ # 空状态组件 utils/ request.js # wx.request 封装 city.js # 城市定位与切换逻辑 format.js # 时间、价格、浏览量格式化 api/ index.js # 接口地址集中管理每个页面在app.json里注册时路由表建议这样规划同时决定参数怎么传页面路径路由名称携带参数参数用途/pages/index/index首页city当前城市编码/pages/list/list列表页categoryId, city, page, keyword分类、城市、分页、搜索词/pages/detail/detail详情页infoId信息唯一 ID/pages/publish/publish发布页categoryId发布时预选分类路由参数不要设计得太丰富能用一个infoId解决的绝对不要传整个对象。小程序页面栈有层级限制参数塞太多不仅 URL 难看在分享、扫码进入场景下还会因为参数缺失导致页面白屏。常见的做法是只传 ID详情内容进入页面后按 ID 请求。2.2 数据请求层怎么封装拦截器和错误处理放哪仿58同城的前端有大量列表接口、详情接口和发布接口如果每个页面直接调wx.request项目写一半就会陷入重复代码的泥潭。封装一个utils/request.js是开工第一步也是最值得先写的工具。// utils/request.js const BASE_URL https://api.example.com/v1 // 接口根地址 function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${path}, method, data, header: { Content-Type: application/json, X-User-Token: wx.getStorageSync(token) || }, success(res) { // 业务约定code 0 为成功非 0 为业务异常 if (res.statusCode 200 res.data.code 0) { resolve(res.data.data) } else if (res.statusCode 401) { // token 过期跳登录 wx.navigateTo({ url: /pages/login/login }) reject(res.data) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res.data) } }, fail(err) { wx.showToast({ title: 网络异常请检查网络, icon: none }) reject(err) } }) }) } module.exports { get: (path, data) request(path, GET, data), post: (path, data) request(path, POST, data) }这段代码的逻辑说明成功回调里先判断 HTTP 状态码再判断业务码两层分开处理是仿58类前端最常见的接口约定。code为 0 时只返回data.data把包裹层剥掉页面拿到的就是干净的业务数据。401 单独拦截跳登录避免每个页面重复写“请先登录”的弹窗。fail对应的是断网、超时、DNS 解析失败这类无响应场景和业务异常要区分开给用户提示“网络异常”而不是把一串 undefined 渲染到页面上。参数层面要注意三个点method默认走 GET但发布、删除这类写操作一定要显式传 POSTX-User-Token从 storage 里每次读取避免登录态变更后 token 不刷新BASE_URL不要写死域名后续上线换正式域名时只需改一处。另外建议给request.js加一个超时时间wx.request默认超时 60 秒信息列表这类接口拖到 10 秒以上就该主动断开体验上和用户感知的“卡死”完全不同。3. 首页信息流和分类导航的前端实现导航栏高度这样适配3.1 分类宫格数据驱动前端不写死图标和名称58同城系产品首页最大的特征是分类多、入口密招聘、房产、二手车、二手物品、生活服务等十几个分类挤在首屏。仿写时最容易犯的错是把分类写死在WXML里十二个view堆着换一个分类或调整排序就要改页面代码。正确做法是把分类配成数据源页面只负责渲染。常见做法是前端维护一份分类配置或者由后端接口下发分类列表。本地宝这类带城市属性的分类平台分类往往随城市开通的类目不同而变化所以更推荐接口下发。先给出数据驱动的渲染代码// pages/index/index.js Page({ data: { categories: [ { id: 101, name: 招聘, icon: /assets/job.png, color: #00A2E8 }, { id: 102, name: 房产, icon: /assets/house.png, color: #FF6B35 }, { id: 103, name: 二手车, icon: /assets/car.png, color: #00B386 }, { id: 104, name: 二手物品, icon: /assets/used.png, color: #F5A623 } // 实际开发中由接口返回 ] }, onTapCategory(e) { const { id, name } e.currentTarget.dataset wx.navigateTo({ url: /pages/list/list?categoryId${id}categoryName${name} }) } })!-- pages/index/index.wxml -- view classcategory-grid view classcategory-item wx:for{{categories}} wx:keyid >// 信息流列表合并置顶数据 const normalList res.data.list || [] const topList res.data.topList || [] this.setData({ list: [...topList.map(item ({ ...item, isTop: true })), ...normalList] })置顶数据放到最前面展示是58同类产品的默认策略。注意这里不要做前端排序接口已经排好序时前端保持顺序即可只有在接口没有区分置顶字段时才需要前端手动合并。3.2 信息流分页请求前端该做什么不该做什么信息流列表的分页是仿58类前端最关键的性能设计。一个城市一个分类下可能有几万条信息一次性加载既慢又耗内存。常见的处理方式是“分页 触底加载”// pages/list/list.js Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, // 上拉触底加载 onReachBottom() { if (!this.data.hasMore || this.data.loading) return this.loadList() }, async loadList() { if (this.data.loading) return this.setData({ loading: true }) const { page, pageSize } this.data try { const res await api.getList({ page, pageSize }) const newList res.list || [] this.setData({ list: this.data.list.concat(newList), page: page 1, hasMore: newList.length pageSize }) } finally { this.setData({ loading: false }) } } })逻辑说明onReachBottom是微信小程序页面自带的上拉触底事件不需要自己监听滚动位置。loading标志防止触底事件连续触发时发出重复请求hasMore根据返回条数是否等于pageSize判断是否还有下一页。这里有个容易踩的坑分页的“页数”完全由前端维护每次请求用当前page成功后立即page 1。如果页面加了筛选条件切换筛选时必须把list清空、page重置为 1否则旧数据会混在新数据里。前端在分页上不该做的事有两件第一不要把pageSize设得过大。列表页 10 到 20 条一页最合适超过 20 条首屏渲染时间会明显变长第二不要依赖onReachBottom处理所有滚动场景。如果 list 页嵌在 scroll-view 里触底事件是不生效的这时要改用bindscrolltolower并设置lower-threshold参数常见阈值设为 100 像素左右让用户在滚到底之前就触发下一轮加载。列表项渲染建议用微信原生的wx:for而不是模板字符串拼接。每条卡片数据量控制在十几个字段以内图片懒加载用lazy-load属性开启减少首屏请求数。3.3 小程序动态设置标题和顶部导航栏高度适配仿58同城的前端页面导航栏标题不是写死的。列表页进入时显示“分类名 城市名”详情页显示“信息详情”发布页显示“我要发布”。微信小程序原生导航栏支持动态修改标题// 列表页 onLoad 里动态设置标题 onLoad(options) { const { categoryName, city 全部 } options wx.setNavigationBarTitle({ title: ${categoryName} - ${city} }) }wx.setNavigationBarTitle是页面内动态改标题的标准接口。它只接受字符串不需要在app.json里预先声明每个页面的标题。注意设置时机在onLoad中执行如果接口返回后才拿到分类名就需要在接口回调里再次调用。标题长度建议控制在 12 个字以内超过会被微信截断。除了标题导航栏还有更棘手的高度适配问题。微信小程序的胶囊按钮右上角的“…”和“○”高度是固定的但不同型号手机的导航栏高度不同。做自定义导航栏时需要动态计算状态栏高度和胶囊位置。如果是原生导航栏这块不需要操心一旦为了视觉统一用自定义导航栏比如首页需要沉浸式头图就必须处理// app.js 或工具函数中计算 const getNavHeight () { const systemInfo wx.getSystemInfoSync() const menuButtonInfo wx.getMenuButtonBoundingClientRect() // 胶囊底部到状态栏底部的距离加上胶囊高度的一半得到导航栏中心 const navBarHeight (menuButtonInfo.top - systemInfo.statusBarHeight) * 2 menuButtonInfo.height return { statusBarHeight: systemInfo.statusBarHeight, navBarHeight } }代码含义wx.getSystemInfoSync拿到状态栏高度一般 20 到 47 像素不等wx.getMenuButtonBoundingClientRect拿到胶囊按钮的位置和尺寸。导航栏总高度由“状态栏高度 从状态栏底部到胶囊底部的距离”两部分组成计算公式中的(menuButtonInfo.top - statusBarHeight) * 2是在推算胶囊上方的留白对称到下方后的整体高度。这个数值在不同机型上差异明显iPhone 刘海屏和安卓全面屏差出十几像素写死 44 像素或 48 像素都会在真机上偏移。拿到高度后在app.json里把对应页面配置为自定义导航栏{ pages: [pages/index/index], window: { navigationStyle: custom } }navigationStyle设为custom后页面顶部会完全交给前端绘制。此时给页面根节点设置padding-top: {{navBarHeight}}px或在自定义nav-bar组件里把高度绑成动态值。注意设为custom后wx.setNavigationBarTitle不再生效标题文本需要自己在自定义导航栏组件中通过data传入。所以用原创导航栏还是自定义导航栏要在一开始就定好不要中途切换否则每个页面的标题和高度适配都要重做。4. 列表筛选、详情页浏览数和发布页校验的前端实现4.1 列表页筛选条件与直达触底参数怎么带才不乱58同城风格列表页筛选条件是标配区域、价格区间、发布时间、排序方式。这些条件在仿写时集中在一个问题——筛选参数如何管理。常见做法是把所有筛选条件放到一个filter对象里每次修改条件时同步更新并重新拉列表。// pages/list/list.js Page({ data: { filter: { region: , priceMin: , priceMax: , publishTime: , orderBy: default, // default: 默认排序, newest: 最新发布 categoryId: } }, // 筛选面板点击区域后更新条件 onSelectRegion(e) { const { regionId } e.currentTarget.dataset this.setData({ filter.region: regionId, list: [], page: 1 }) this.loadList() } }).setData中直接修改嵌套对象的属性路径filter.region比整体覆盖filter再传回性能更好也避免其他筛选字段被误清空。筛选条件变化后要做的三件事是清空现有列表、重置页码、重新请求。很多人漏掉重置page导致筛选后从第 5 页开始加载前面几页数据直接消失。筛选条件在请求接口时统一展开成查询参数// 展开 filter 为接口参数字段 const params { categoryId: this.data.filter.categoryId, region: this.data.filter.region, priceMin: this.data.filter.priceMin || undefined, priceMax: this.data.filter.priceMax || undefined, orderBy: this.data.filter.orderBy, page: this.data.page, pageSize: this.data.pageSize } api.getList(params)priceMin和priceMax为空字符串时要转成undefined否则接口可能收到空参数导致 SQL 拼接出错。categoryId从路由参数中取出后写入filter对象这样筛选面板和请求函数都只读filter一种数据结构不用考虑参数来自路由还是用户点击。筛选场景需要重置列表需要重置页码需要重新请求切换区域是是是修改价格区间是是是切换排序方式是是是上拉加载更多否否是表格说明前三类操作属于“条件变更”语义上等价于一次全新查询必须重置最后一类是纯增量加载只追加数据。这个表格是前端写列表筛选时最容易错的地方把“条件变更”和“数据追加”两类操作区分清楚列表的逻辑就干净了。4.2 详情页信息层级与浏览计数怎么避免反复刷新详情页是58同城类产品的信任核心一个二手手机、一条招聘信息能否成交取决于信息展示的完整度。前端要做的是把信息层级理清楚。常见的页面结构分三段第一段是标题和价格第二段是核心属性成色、区域、联系人、发布时间第三段是图文描述和发布者信息。这三段要在一个页面里按视觉重力排布不能用滚动列表堆到 UV 里才算完。浏览计数是详情页一个特殊的前端问题。每次进入详情页都请求一次浏览 1 接口会带来两个结果一是用户反复进出导致计数虚高二是接口请求量翻倍。常见的做法是只在“从列表页进入详情页”时上报一次浏览或者用转发分享进入时才 1。前端控制方式// 详情页 onLoad 中记录来源 onLoad(options) { this.infoId options.infoId // 只有从列表进入时上报浏览 if (options.from list) { api.reportView({ infoId: this.infoId }) } }options.from在列表页跳转时塞入路由参数详情页在onLoad里判断来源后决定是否上报。这样设计后用户停留在详情页反复下拉刷新不会重复计数而通过分享卡片进入的详情页自带曝光属性天然就是一次有效浏览。注意上报接口用wx.request的fire and forget模式前端不需要等待响应也不用在回调里做任何处理。详情页还有一个容易被忽略的前端点浏览量展示格式。超过一万的浏览量要格式化显示用utils/format.js里的函数// utils/format.js function formatCount(count) { if (count 10000) { return (count / 10000).toFixed(1) 万次浏览 } return count 次浏览 }格式化属于展示层逻辑不要污染数据层。接口返回 20010 时页面展示“2.0万次浏览”这个函数应该放在工具模块里详情页和列表页共用避免两处各写一遍格式化规则。4.3 发布页文本域与图片上传前端校验做在哪一层发布页是仿58类前端的“负债”页面对前端而言表单字段多、交互状态复杂。以二手物品发布为例常见字段是标题、描述、价格、图片、联系方式、所在区域。前端要做两件事表单校验和图片上传。校验不放在点击发布时才一次性检查而是在每个字段blur时检查并给出即时反馈// pages/publish/publish.js Page({ data: { form: { title: , desc: , price: , images: [], contact: }, errors: {} }, onTitleBlur(e) { const title e.detail.value.trim() const errors { ...this.data.errors } if (title.length 5) { errors.title 标题至少 5 个字 } else { delete errors.title } this.setData({ form.title: title, errors }) }, onSubmit() { const errors this.validateAll(this.data.form) if (Object.keys(errors).length 0) { this.setData({ errors }) wx.showToast({ title: 请检查必填项, icon: none }) return } this.submitForm() } })blur时校验是为了在用户离开输入框的那一刻就发现问题而点击提交时再全量校验一次兜底。两层校验并不重复——前者提升体验后者保证数据完整。校验规则里不要只判空标题和描述都有长度下限价格要校验parseFloat后大于 0联系方式用正则匹配手机号。图片上传要用wx.chooseMedia选图再逐个调上传接口// 选择并上传图片最多 9 张 async onChooseImage() { const remain 9 - this.data.form.images.length const res await wx.chooseMedia({ count: remain, mediaType: [image], sizeType: [compressed] }) const tasks res.tempFiles.map(file this.uploadOne(file.tempFilePath)) const urls await Promise.all(tasks) this.setData({ form.images: this.data.form.images.concat(urls) }) }wx.chooseMedia比旧版wx.chooseImage更推荐它支持视频和图片统一选择sizeType: [compressed]会默认压缩图片避免用户直接拍一张 10MB 的照片上传。Promise.all并发上传多张图片会比串行快但要控制并发数一次性上传 9 张时建议拆成每次 3 张并发否则弱网环境下容易超时失败。上传进度提示可以简单用一个 loadingwx.showLoading覆盖不推荐做复杂的进度条投资回报率不划算。5. 前端自测的一个硬技巧接口数据对不上时先改这里仿58同城小程序开发后期八成时间不是在写新页面而是在对付“接口返回的数据和页面预期不一致”。第一类是字段名对不上后端返回user_name前端写的是username渲染出来一片空白第二类是数据结构嵌套层级不同后端把列表放在res.data.list前端却去读res.data.records第三类是类型不一致接口返回价格的字符串1999前端直接用加减运算得到字符串拼接的结果。一个有效的技巧是在utils/request.js的resolve之前加一行日志打印把每个请求的 URL、参数和返回数据打出来if (res.statusCode 200 res.data.code 0) { console.log([API] ${method} ${path}, { params: data, response: res.data }) resolve(res.data.data) }真机调试时打开调试器的 Console 面板请求发出后立刻能看到接口返回的原始 JSON。格式化输出对象而不是字符串拼接Console 里可以展开看每一层结构对比页面渲染实际取值的位置问题往往一眼就找到了。这个方法适合任何小程序页面排查列表不显示、详情空白、筛选无效这些常规问题时先看日志再改代码比盲改快得多。第二个实用技巧是准备一份本地 mock 数据文件。当前端页面写完但后端接口还没就绪时把约定好的返回结构写进一个mock.js在请求封装里加一个开关// utils/request.js const USE_MOCK false // 本地调试改为 true if (USE_MOCK) { const mockData require(./mock.js) resolve(mockData[path] || {}) return }mock 数据只用于前端把页面渲染跑起来接口联调时要记得把USE_MOCK改回false。有人会把 mock 逻辑直接写在 Page 代码里联调时又要删代码容易留垃圾。放在请求层统一控制改一个开关就能切换真实接口和模拟数据是最省事的方式。动态标题的验证也有快路径进入列表页后打开右上角胶囊按钮的“重新进入小程序”功能观察标题是否在页面加载瞬间就被修改。小程序在冷启动时会先加载app.json里的默认标题再执行页面onLoad的wx.setNavigationBarTitle如果设置时机在异步回调里可能出现标题先显示默认值、再跳变的情况。验证时关注的是跳变是否在首屏渲染完成前完成以及不同机型上标题是否被胶囊遮挡。把这个细节调好导航栏体验基本就过关了。本文还有配套的精品资源点击获取 本地宝仿58同城小程序前端开发实战：从选型到自测
简介一份仿58同城风格的本地生活小程序前端源码适合正在学习微信小程序开发或需要快速搭建本地信息服务类应用的开发者。资源压缩包共14个文件体积仅487KB11张图片资源配合app.json全局配置、app.js应用逻辑与app.wxss公共样式能快速梳理小程序从启动到页面渲染的基础结构。源码还包含页面目录、工具函数、图片资源和请求模块等常见工程划分覆盖数据绑定、事件处理、路由跳转与网络请求等核心知识点整体目录结构清晰便于学习者按模块阅读。已有497人学习下载既可以作为系统学习微信小程序的实战参考也能拿来当作课设/毕设或商业项目起步模板通过替换数据、接口与样式即可搭建同城信息、租房招聘等场景的可用原型。1. 本地宝仿58同城小程序源码下载前先拆清楚前端要做什么搜“本地宝仿58同城小程序源码下载前端”的人通常不是缺那几 MB 的代码包而是拿到源码后发现跑不起来、页面和真机对不上、接口报错一片红。仿58同城这类分类信息小程序前端核心就三件事城市切换、分类信息流、详情页与发布页。本地宝的形态更像“城市生活服务入口”把招聘、房产、二手、家政、转让这些类目塞进一个小程序首页信息密度比普通商城高一个量级。本文不评价任何一份具体源码的好坏只把做这类前端时最常见的取舍、分页策略、导航栏适配和自测方法讲清楚。新手照着搭能少走弯路五年以上经验的人看参数边界和容错设计也会有可搬的东西。2. 仿58同城小程序前端的选型、目录结构与数据请求层2.1 微信原生小程序还是 uniapp选型差别在哪拿到标题里的“小程序源码前端”第一步先分清它是微信原生小程序还是 uniapp 工程。原生小程序的典型特征是有app.json、pages目录、WXML文件uniapp 工程则是一套src/pagesvue文件编译后才产出小程序代码。判断错了后面所有调试都会在错误的方向上浪费时间。微信原生小程序适合团队长期只做微信端、要深挖微信能力的场景订阅消息、私域分享、实时定位接口、蓝牙等原生能力调用最直接没有跨端框架的编译层干扰。uniapp 适合后面想同时出支付宝小程序、抖音小程序或 App 的场景一套 Vue 代码多端发布但代价是部分微信特性要绕一层 API 兼容层。本地宝和58同城这类信息平台绝大多数流量在微信内我一般建议直接上微信原生理由很简单这类项目的核心页面是信息流和详情页对列表渲染性能、滚动流畅度要求高原生小程序的 setData 虽然限制多但行为最可控。2.1.1 工程结构的骨架和页面路由表先建一个标准的微信小程序前端结构目录划分按“页面 组件 工具 接口”四层来组织pages/ index/ # 首页城市切换 分类宫格 信息流 list/ # 列表页按分类、区域、筛选条件展示 detail/ # 详情页信息内容 联系方式 浏览计数 publish/ # 发布页标题、描述、图片、联系方式 mine/ # 我的发布记录、收藏、足迹 components/ nav-bar/ # 自定义导航栏组件 news-card/ # 信息流卡片组件 empty-view/ # 空状态组件 utils/ request.js # wx.request 封装 city.js # 城市定位与切换逻辑 format.js # 时间、价格、浏览量格式化 api/ index.js # 接口地址集中管理每个页面在app.json里注册时路由表建议这样规划同时决定参数怎么传页面路径路由名称携带参数参数用途/pages/index/index首页city当前城市编码/pages/list/list列表页categoryId, city, page, keyword分类、城市、分页、搜索词/pages/detail/detail详情页infoId信息唯一 ID/pages/publish/publish发布页categoryId发布时预选分类路由参数不要设计得太丰富能用一个infoId解决的绝对不要传整个对象。小程序页面栈有层级限制参数塞太多不仅 URL 难看在分享、扫码进入场景下还会因为参数缺失导致页面白屏。常见的做法是只传 ID详情内容进入页面后按 ID 请求。2.2 数据请求层怎么封装拦截器和错误处理放哪仿58同城的前端有大量列表接口、详情接口和发布接口如果每个页面直接调wx.request项目写一半就会陷入重复代码的泥潭。封装一个utils/request.js是开工第一步也是最值得先写的工具。// utils/request.js const BASE_URL https://api.example.com/v1 // 接口根地址 function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${path}, method, data, header: { Content-Type: application/json, X-User-Token: wx.getStorageSync(token) || }, success(res) { // 业务约定code 0 为成功非 0 为业务异常 if (res.statusCode 200 res.data.code 0) { resolve(res.data.data) } else if (res.statusCode 401) { // token 过期跳登录 wx.navigateTo({ url: /pages/login/login }) reject(res.data) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res.data) } }, fail(err) { wx.showToast({ title: 网络异常请检查网络, icon: none }) reject(err) } }) }) } module.exports { get: (path, data) request(path, GET, data), post: (path, data) request(path, POST, data) }这段代码的逻辑说明成功回调里先判断 HTTP 状态码再判断业务码两层分开处理是仿58类前端最常见的接口约定。code为 0 时只返回data.data把包裹层剥掉页面拿到的就是干净的业务数据。401 单独拦截跳登录避免每个页面重复写“请先登录”的弹窗。fail对应的是断网、超时、DNS 解析失败这类无响应场景和业务异常要区分开给用户提示“网络异常”而不是把一串 undefined 渲染到页面上。参数层面要注意三个点method默认走 GET但发布、删除这类写操作一定要显式传 POSTX-User-Token从 storage 里每次读取避免登录态变更后 token 不刷新BASE_URL不要写死域名后续上线换正式域名时只需改一处。另外建议给request.js加一个超时时间wx.request默认超时 60 秒信息列表这类接口拖到 10 秒以上就该主动断开体验上和用户感知的“卡死”完全不同。3. 首页信息流和分类导航的前端实现导航栏高度这样适配3.1 分类宫格数据驱动前端不写死图标和名称58同城系产品首页最大的特征是分类多、入口密招聘、房产、二手车、二手物品、生活服务等十几个分类挤在首屏。仿写时最容易犯的错是把分类写死在WXML里十二个view堆着换一个分类或调整排序就要改页面代码。正确做法是把分类配成数据源页面只负责渲染。常见做法是前端维护一份分类配置或者由后端接口下发分类列表。本地宝这类带城市属性的分类平台分类往往随城市开通的类目不同而变化所以更推荐接口下发。先给出数据驱动的渲染代码// pages/index/index.js Page({ data: { categories: [ { id: 101, name: 招聘, icon: /assets/job.png, color: #00A2E8 }, { id: 102, name: 房产, icon: /assets/house.png, color: #FF6B35 }, { id: 103, name: 二手车, icon: /assets/car.png, color: #00B386 }, { id: 104, name: 二手物品, icon: /assets/used.png, color: #F5A623 } // 实际开发中由接口返回 ] }, onTapCategory(e) { const { id, name } e.currentTarget.dataset wx.navigateTo({ url: /pages/list/list?categoryId${id}categoryName${name} }) } })!-- pages/index/index.wxml -- view classcategory-grid view classcategory-item wx:for{{categories}} wx:keyid >// 信息流列表合并置顶数据 const normalList res.data.list || [] const topList res.data.topList || [] this.setData({ list: [...topList.map(item ({ ...item, isTop: true })), ...normalList] })置顶数据放到最前面展示是58同类产品的默认策略。注意这里不要做前端排序接口已经排好序时前端保持顺序即可只有在接口没有区分置顶字段时才需要前端手动合并。3.2 信息流分页请求前端该做什么不该做什么信息流列表的分页是仿58类前端最关键的性能设计。一个城市一个分类下可能有几万条信息一次性加载既慢又耗内存。常见的处理方式是“分页 触底加载”// pages/list/list.js Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, // 上拉触底加载 onReachBottom() { if (!this.data.hasMore || this.data.loading) return this.loadList() }, async loadList() { if (this.data.loading) return this.setData({ loading: true }) const { page, pageSize } this.data try { const res await api.getList({ page, pageSize }) const newList res.list || [] this.setData({ list: this.data.list.concat(newList), page: page 1, hasMore: newList.length pageSize }) } finally { this.setData({ loading: false }) } } })逻辑说明onReachBottom是微信小程序页面自带的上拉触底事件不需要自己监听滚动位置。loading标志防止触底事件连续触发时发出重复请求hasMore根据返回条数是否等于pageSize判断是否还有下一页。这里有个容易踩的坑分页的“页数”完全由前端维护每次请求用当前page成功后立即page 1。如果页面加了筛选条件切换筛选时必须把list清空、page重置为 1否则旧数据会混在新数据里。前端在分页上不该做的事有两件第一不要把pageSize设得过大。列表页 10 到 20 条一页最合适超过 20 条首屏渲染时间会明显变长第二不要依赖onReachBottom处理所有滚动场景。如果 list 页嵌在 scroll-view 里触底事件是不生效的这时要改用bindscrolltolower并设置lower-threshold参数常见阈值设为 100 像素左右让用户在滚到底之前就触发下一轮加载。列表项渲染建议用微信原生的wx:for而不是模板字符串拼接。每条卡片数据量控制在十几个字段以内图片懒加载用lazy-load属性开启减少首屏请求数。3.3 小程序动态设置标题和顶部导航栏高度适配仿58同城的前端页面导航栏标题不是写死的。列表页进入时显示“分类名 城市名”详情页显示“信息详情”发布页显示“我要发布”。微信小程序原生导航栏支持动态修改标题// 列表页 onLoad 里动态设置标题 onLoad(options) { const { categoryName, city 全部 } options wx.setNavigationBarTitle({ title: ${categoryName} - ${city} }) }wx.setNavigationBarTitle是页面内动态改标题的标准接口。它只接受字符串不需要在app.json里预先声明每个页面的标题。注意设置时机在onLoad中执行如果接口返回后才拿到分类名就需要在接口回调里再次调用。标题长度建议控制在 12 个字以内超过会被微信截断。除了标题导航栏还有更棘手的高度适配问题。微信小程序的胶囊按钮右上角的“…”和“○”高度是固定的但不同型号手机的导航栏高度不同。做自定义导航栏时需要动态计算状态栏高度和胶囊位置。如果是原生导航栏这块不需要操心一旦为了视觉统一用自定义导航栏比如首页需要沉浸式头图就必须处理// app.js 或工具函数中计算 const getNavHeight () { const systemInfo wx.getSystemInfoSync() const menuButtonInfo wx.getMenuButtonBoundingClientRect() // 胶囊底部到状态栏底部的距离加上胶囊高度的一半得到导航栏中心 const navBarHeight (menuButtonInfo.top - systemInfo.statusBarHeight) * 2 menuButtonInfo.height return { statusBarHeight: systemInfo.statusBarHeight, navBarHeight } }代码含义wx.getSystemInfoSync拿到状态栏高度一般 20 到 47 像素不等wx.getMenuButtonBoundingClientRect拿到胶囊按钮的位置和尺寸。导航栏总高度由“状态栏高度 从状态栏底部到胶囊底部的距离”两部分组成计算公式中的(menuButtonInfo.top - statusBarHeight) * 2是在推算胶囊上方的留白对称到下方后的整体高度。这个数值在不同机型上差异明显iPhone 刘海屏和安卓全面屏差出十几像素写死 44 像素或 48 像素都会在真机上偏移。拿到高度后在app.json里把对应页面配置为自定义导航栏{ pages: [pages/index/index], window: { navigationStyle: custom } }navigationStyle设为custom后页面顶部会完全交给前端绘制。此时给页面根节点设置padding-top: {{navBarHeight}}px或在自定义nav-bar组件里把高度绑成动态值。注意设为custom后wx.setNavigationBarTitle不再生效标题文本需要自己在自定义导航栏组件中通过data传入。所以用原创导航栏还是自定义导航栏要在一开始就定好不要中途切换否则每个页面的标题和高度适配都要重做。4. 列表筛选、详情页浏览数和发布页校验的前端实现4.1 列表页筛选条件与直达触底参数怎么带才不乱58同城风格列表页筛选条件是标配区域、价格区间、发布时间、排序方式。这些条件在仿写时集中在一个问题——筛选参数如何管理。常见做法是把所有筛选条件放到一个filter对象里每次修改条件时同步更新并重新拉列表。// pages/list/list.js Page({ data: { filter: { region: , priceMin: , priceMax: , publishTime: , orderBy: default, // default: 默认排序, newest: 最新发布 categoryId: } }, // 筛选面板点击区域后更新条件 onSelectRegion(e) { const { regionId } e.currentTarget.dataset this.setData({ filter.region: regionId, list: [], page: 1 }) this.loadList() } }).setData中直接修改嵌套对象的属性路径filter.region比整体覆盖filter再传回性能更好也避免其他筛选字段被误清空。筛选条件变化后要做的三件事是清空现有列表、重置页码、重新请求。很多人漏掉重置page导致筛选后从第 5 页开始加载前面几页数据直接消失。筛选条件在请求接口时统一展开成查询参数// 展开 filter 为接口参数字段 const params { categoryId: this.data.filter.categoryId, region: this.data.filter.region, priceMin: this.data.filter.priceMin || undefined, priceMax: this.data.filter.priceMax || undefined, orderBy: this.data.filter.orderBy, page: this.data.page, pageSize: this.data.pageSize } api.getList(params)priceMin和priceMax为空字符串时要转成undefined否则接口可能收到空参数导致 SQL 拼接出错。categoryId从路由参数中取出后写入filter对象这样筛选面板和请求函数都只读filter一种数据结构不用考虑参数来自路由还是用户点击。筛选场景需要重置列表需要重置页码需要重新请求切换区域是是是修改价格区间是是是切换排序方式是是是上拉加载更多否否是表格说明前三类操作属于“条件变更”语义上等价于一次全新查询必须重置最后一类是纯增量加载只追加数据。这个表格是前端写列表筛选时最容易错的地方把“条件变更”和“数据追加”两类操作区分清楚列表的逻辑就干净了。4.2 详情页信息层级与浏览计数怎么避免反复刷新详情页是58同城类产品的信任核心一个二手手机、一条招聘信息能否成交取决于信息展示的完整度。前端要做的是把信息层级理清楚。常见的页面结构分三段第一段是标题和价格第二段是核心属性成色、区域、联系人、发布时间第三段是图文描述和发布者信息。这三段要在一个页面里按视觉重力排布不能用滚动列表堆到 UV 里才算完。浏览计数是详情页一个特殊的前端问题。每次进入详情页都请求一次浏览 1 接口会带来两个结果一是用户反复进出导致计数虚高二是接口请求量翻倍。常见的做法是只在“从列表页进入详情页”时上报一次浏览或者用转发分享进入时才 1。前端控制方式// 详情页 onLoad 中记录来源 onLoad(options) { this.infoId options.infoId // 只有从列表进入时上报浏览 if (options.from list) { api.reportView({ infoId: this.infoId }) } }options.from在列表页跳转时塞入路由参数详情页在onLoad里判断来源后决定是否上报。这样设计后用户停留在详情页反复下拉刷新不会重复计数而通过分享卡片进入的详情页自带曝光属性天然就是一次有效浏览。注意上报接口用wx.request的fire and forget模式前端不需要等待响应也不用在回调里做任何处理。详情页还有一个容易被忽略的前端点浏览量展示格式。超过一万的浏览量要格式化显示用utils/format.js里的函数// utils/format.js function formatCount(count) { if (count 10000) { return (count / 10000).toFixed(1) 万次浏览 } return count 次浏览 }格式化属于展示层逻辑不要污染数据层。接口返回 20010 时页面展示“2.0万次浏览”这个函数应该放在工具模块里详情页和列表页共用避免两处各写一遍格式化规则。4.3 发布页文本域与图片上传前端校验做在哪一层发布页是仿58类前端的“负债”页面对前端而言表单字段多、交互状态复杂。以二手物品发布为例常见字段是标题、描述、价格、图片、联系方式、所在区域。前端要做两件事表单校验和图片上传。校验不放在点击发布时才一次性检查而是在每个字段blur时检查并给出即时反馈// pages/publish/publish.js Page({ data: { form: { title: , desc: , price: , images: [], contact: }, errors: {} }, onTitleBlur(e) { const title e.detail.value.trim() const errors { ...this.data.errors } if (title.length 5) { errors.title 标题至少 5 个字 } else { delete errors.title } this.setData({ form.title: title, errors }) }, onSubmit() { const errors this.validateAll(this.data.form) if (Object.keys(errors).length 0) { this.setData({ errors }) wx.showToast({ title: 请检查必填项, icon: none }) return } this.submitForm() } })blur时校验是为了在用户离开输入框的那一刻就发现问题而点击提交时再全量校验一次兜底。两层校验并不重复——前者提升体验后者保证数据完整。校验规则里不要只判空标题和描述都有长度下限价格要校验parseFloat后大于 0联系方式用正则匹配手机号。图片上传要用wx.chooseMedia选图再逐个调上传接口// 选择并上传图片最多 9 张 async onChooseImage() { const remain 9 - this.data.form.images.length const res await wx.chooseMedia({ count: remain, mediaType: [image], sizeType: [compressed] }) const tasks res.tempFiles.map(file this.uploadOne(file.tempFilePath)) const urls await Promise.all(tasks) this.setData({ form.images: this.data.form.images.concat(urls) }) }wx.chooseMedia比旧版wx.chooseImage更推荐它支持视频和图片统一选择sizeType: [compressed]会默认压缩图片避免用户直接拍一张 10MB 的照片上传。Promise.all并发上传多张图片会比串行快但要控制并发数一次性上传 9 张时建议拆成每次 3 张并发否则弱网环境下容易超时失败。上传进度提示可以简单用一个 loadingwx.showLoading覆盖不推荐做复杂的进度条投资回报率不划算。5. 前端自测的一个硬技巧接口数据对不上时先改这里仿58同城小程序开发后期八成时间不是在写新页面而是在对付“接口返回的数据和页面预期不一致”。第一类是字段名对不上后端返回user_name前端写的是username渲染出来一片空白第二类是数据结构嵌套层级不同后端把列表放在res.data.list前端却去读res.data.records第三类是类型不一致接口返回价格的字符串1999前端直接用加减运算得到字符串拼接的结果。一个有效的技巧是在utils/request.js的resolve之前加一行日志打印把每个请求的 URL、参数和返回数据打出来if (res.statusCode 200 res.data.code 0) { console.log([API] ${method} ${path}, { params: data, response: res.data }) resolve(res.data.data) }真机调试时打开调试器的 Console 面板请求发出后立刻能看到接口返回的原始 JSON。格式化输出对象而不是字符串拼接Console 里可以展开看每一层结构对比页面渲染实际取值的位置问题往往一眼就找到了。这个方法适合任何小程序页面排查列表不显示、详情空白、筛选无效这些常规问题时先看日志再改代码比盲改快得多。第二个实用技巧是准备一份本地 mock 数据文件。当前端页面写完但后端接口还没就绪时把约定好的返回结构写进一个mock.js在请求封装里加一个开关// utils/request.js const USE_MOCK false // 本地调试改为 true if (USE_MOCK) { const mockData require(./mock.js) resolve(mockData[path] || {}) return }mock 数据只用于前端把页面渲染跑起来接口联调时要记得把USE_MOCK改回false。有人会把 mock 逻辑直接写在 Page 代码里联调时又要删代码容易留垃圾。放在请求层统一控制改一个开关就能切换真实接口和模拟数据是最省事的方式。动态标题的验证也有快路径进入列表页后打开右上角胶囊按钮的“重新进入小程序”功能观察标题是否在页面加载瞬间就被修改。小程序在冷启动时会先加载app.json里的默认标题再执行页面onLoad的wx.setNavigationBarTitle如果设置时机在异步回调里可能出现标题先显示默认值、再跳变的情况。验证时关注的是跳变是否在首屏渲染完成前完成以及不同机型上标题是否被胶囊遮挡。把这个细节调好导航栏体验基本就过关了。本文还有配套的精品资源点击获取