# 技术选型与落地

本篇适用于采用公司四个新通平台脚手架的新项目。技术栈已经确定：从四个仓库拉取代码，在现有框架、依赖、目录和构建方式上开发；开发 Agent 不自行选择另一套前后端框架、ORM、组件库或包管理器。具体版本以各仓当前锁文件和构建配置为准。维护不使用这些脚手架的存量项目时，以该项目现有约定为准。

## 固定的四仓技术栈

| 仓库 | 技术栈 | 负责的交付物 |
| --- | --- | --- |
| `xt-platform-java` | Java 17、Spring Boot、Maven、MyBatis-Plus、MySQL、Redis | 服务端 API、身份与权限、业务规则和持久化；构建可运行 JAR。 |
| `xt-platform-admin` | Vue 3、TypeScript、Vite、Element Plus、Pinia、pnpm | 独立管理后台；构建静态 SPA。 |
| `xt-platform-web` | Nuxt 4、Vue 3、TypeScript、Pinia、pnpm | 电脑与手机浏览器前台；构建需要 Node 运行的 SSR 应用。 |
| `xt-platform-uniApp` | uni-app、Vue 3、TypeScript、Pinia、pnpm | H5、微信小程序和 App 前台；按目标平台分别构建。 |

四仓有各自的 `README.md`、`AGENTS.md`、项目 Skill 和开发文档。先读目标仓库的当前约定，再按用户需求修改对应仓库；不要把本站概括的版本号、命令或目录当成比仓库文件更新的事实。四仓的已实现范围、修订时间和待联调事项见[脚手架当前能力与待联调事项](four-repository-starters.md)。

## 在既定技术栈内开发

先确定当前需求涉及哪些端，以及服务端业务归属。管理端沿用现有页面、请求封装和 `/admin-api` 契约；浏览器前台沿用 Nuxt 的页面与请求层；跨端前台沿用 uni-app 的请求层和平台构建；服务端沿用既有模块、权限和数据访问方式。新增业务能力时，把后端规则、数据与授权接到真实 API，再让需要的端调用它，不用 mock 或静态成功结果代替完成。

不因单个功能引入另一套前端框架、服务端框架、ORM、UI 组件库、路由或请求客户端。脚手架已有 Redis、租户、上传等基础能力，按当前需求使用和配置；功能没有要求的部分不必做额外集成。跨仓边界和部署差异见[四仓项目蓝图](project-blueprint.md)。

## 构建和环境不能混为一谈

Java 服务需要 MySQL、Redis 等实际配置；其初始化 SQL 含 `DROP`，只可用于确认的新建隔离库。管理端 `dist-prod` 由静态服务托管，配置需在构建时正确注入。Nuxt 产物需要 Node 服务及真实 API 路由，不能当静态 `dist/` 发布。uni-app 的 H5、微信和 App 产物需要分别验证；单一平台构建通过不代表所有端可用。

每个仓库使用自己的 Node/pnpm 版本及锁文件。运行当前仓库规定的检查，并完成涉及端的真实链路联调；构建成功不等于权限、数据和部署已验收。