十一万樱桃0. 引言
做厦门周边游小程序这个项目，最初的核心诉求其实很简单：帮来厦门旅游的人快速找到周边值得玩的路线、景点和本地特色。但落地到技术上，它就是一个典型的“微信小程序前端 + Node.js后端”组合。小程序端负责展示地图、景点列表、路线推荐、用户登录和收藏，后端则通过Node.js提供接口，管理景点数据、用户信息和收藏记录。
之所以选Node.js而不是Java或Python，主要原因是这个项目体量不大，前端小程序和后端接口可以共用JavaScript语言栈，开发效率非常高。尤其是做景点搜索、路线推荐这类偏IO密集型的业务，Node.js的异步非阻塞模型非常合适。再加上Express这个轻量框架，几天时间就能把整套接口跑起来。微信小程序的生态这几年已经非常成熟，从用户登录、支付到消息推送都有现成能力，对接起来并不费劲。
这篇博文会完整拆解这个项目的实现过程，从Node.js后端环境搭建、Express接口设计、小程序端页面开发，到前后端联调时那些坑爹的问题。重点讲清楚每一步为什么这么做，以及我实测踩过的坑。如果你手上正打算做一个“小程序 + Node.js”的旅游类或本地生活类项目，这篇内容可以直接当参考。
1. 整体设计思路：为什么是“小程序 + Node.js”这个组合
1.1 技术选型背后的理由
单纯从小程序端来看，微信官方其实提供了云开发能力，不用自建服务器就能搞定后端。但我在这个项目里坚持用了自己的Node.js服务器，原因有三个。
第一，数据自由度。云开发的数据库虽然方便，但导出、迁移、多环境管理都比较受限。周边游平台后续要接第三方的景点数据、酒店库存、天气接口，这些数据进来之后要做清洗和聚合，放自己服务器上更好操作。第二，接口的灵活性。景点搜索的排序规则、路线的推荐算法、用户行为的埋点上报，这类逻辑放到后端接口里做，比在小程序端做要干净得多。页面只管渲染，业务逻辑全交给API。第三，部署可控性。Node.js服务部署到云服务器上，配合PM2做进程守护，在整个开发调试阶段响应速度非常直观。我本地起服务，小程序开发工具里直接连局域网IP，改完代码热重载，整个联调链路非常顺。
后端我用了Express 4.x，没上NestJS这类重框架。这个项目就十几个接口，用Express的中间件机制处理登录鉴权、参数校验、日志记录，完全够用。再加一个mysql2连接池操作MySQL数据库，简单直接。
1.2 数据库设计：三张核心表，别贪多
很多刚做小程序的人一上来就设计十几张表，其实对于周边游平台这个体量，三张核心表就够了。
用户表（users）存openid、昵称、头像、创建时间。景点表（spots）存名称、简介、图片、坐标、评分、门票类别。收藏表（favorites）存用户ID和景点ID的关联关系。如果要加路线功能，再加一张routes表，但核心架构不变。这种设计的好处是表关联简单，接口写起来不绕，后续要扩展评论、订单功能时，再加表也不会影响现有结构。
我用Sequelize做ORM，其实用原生SQL也行。但考虑到项目里要写几个联表查询，比如“查询我收藏的景点列表”，Sequelize的include语法能省不少事。
1.3 小程序端项目结构
小程序端我用的原生框架，没用uni-app。原因是这个项目只针对微信小程序一个端，原生框架调试最直接，而且小程序原生的组件和API文档最全，遇到问题搜索答案也容易。
整个前端结构分四块：页面、组件、工具库、请求封装。页面包括首页、景点列表、路线推荐、个人中心；组件是景点卡片、搜索栏这类可复用单元；工具库存放坐标转换、格式化时间这类函数；请求封装统一处理wx.request，带token、处理错误码。
2. 核心细节解析：Node.js后端环境搭建与接口开发
2.1 Node.js安装与环境配置的坑
为什么单独拎出来说环境配置？因为我在这个项目上浪费的时间，一半都花在环境问题上。很多新手在Wi