80 lines
3.7 KiB
Markdown
80 lines
3.7 KiB
Markdown
|
# 技术选型与全景图
|
|||
|
|
|
|||
|
|
**我是卡若。**
|
|||
|
|
|
|||
|
|
选技术跟选合伙人一样，不求最贵的，但求最稳的。
|
|||
|
|
|
|||
|
|
我们要做的是一个**高并发读取、低频次写入、极度依赖 SEO** 的内容变现系统。
|
|||
|
|
|
|||
|
|
基于这个业务特征，我把整个技术栈扒得干干净净，列在这里。
|
|||
|
|
|
|||
|
|
## 1. 技术栈一览表 (Tech Stack)
|
|||
|
|
|
|||
|
|
| 领域 | 选型 | 理由 | 替代方案 (为何不用) |
|
|||
|
|
| :--- | :--- | :--- | :--- |
|
|||
|
|
| **框架** | **Next.js 14 (App Router)** | SSR 对 SEO 极度友好；React 生态最强；Vercel 亲儿子部署方便。 | Vue/Nuxt (生态略逊), Pure React (无 SEO) |
|
|||
|
|
| **语言** | **TypeScript** | 类型安全，重构不慌。 | JavaScript (维护是噩梦) |
|
|||
|
|
| **样式** | **Tailwind CSS** | 写得快，原子化，体积小。 | CSS Modules (写得慢), Styled Components (运行时开销) |
|
|||
|
|
| **UI 库** | **Shadcn UI** | 复制粘贴即用，拥有代码所有权，方便魔改。 | Ant Design (太重，风格太 B 端), MUI (太丑) |
|
|||
|
|
| **数据库** | **MongoDB** | Schema-free，适合存文章、评论这种非结构化数据。 | MySQL (表结构变更麻烦), PostgreSQL (太重) |
|
|||
|
|
| **部署** | **Vercel** | 零配置，全球 CDN，自动 HTTPS。 | 阿里云/腾讯云 ECS (还得自己运维 Nginx) |
|
|||
|
|
| **状态管理** | **Zustand** | 极简，比 Redux 少写 80% 代码。 | Redux (太啰嗦), Recoil (已死) |
|
|||
|
|
| **包管理** | **pnpm** | 速度快，省磁盘空间。 | npm (慢), yarn (幽灵依赖) |
|
|||
|
|
|
|||
|
|
## 2. 架构全景流程图
|
|||
|
|
|
|||
|
|
这是一张让我们可以“闭眼开发”的地图。
|
|||
|
|
|
|||
|
|
\`\`\`mermaid
|
|||
|
|
graph TD
|
|||
|
|
%% 用户接入层
|
|||
|
|
subgraph "用户接入 (User Access)"
|
|||
|
|
User[用户] -->|HTTPS| CDN[Vercel Edge Network]
|
|||
|
|
CDN -->|静态资源| Static[静态文件 (JS/CSS/Img)]
|
|||
|
|
CDN -->|动态请求| NextServer[Next.js Server]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
%% 应用服务层
|
|||
|
|
subgraph "应用服务 (Application)"
|
|||
|
|
NextServer -->|Page Request| SSR[服务端渲染 (SSR)]
|
|||
|
|
NextServer -->|API Request| API[API Routes]
|
|||
|
|
|
|||
|
|
SSR -->|获取数据| DataLayer[数据访问层 (DAL)]
|
|||
|
|
API -->|业务逻辑| Service[业务服务 (Service)]
|
|||
|
|
|
|||
|
|
Service -->|调用| DataLayer
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
%% 数据存储层
|
|||
|
|
subgraph "数据存储 (Data Storage)"
|
|||
|
|
DataLayer -->|读取 Markdown| FileSys[文件系统 (book/)]
|
|||
|
|
DataLayer -->|读写动态数据| MongoDB[(MongoDB Atlas)]
|
|||
|
|
DataLayer -->|缓存热数据| Redis[(Redis - 规划中)]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
%% 外部服务层
|
|||
|
|
subgraph "外部集成 (External)"
|
|||
|
|
API -->|消息通知| Feishu[飞书 Webhook]
|
|||
|
|
API -->|支付回调| WechatPay[微信支付]
|
|||
|
|
end
|
|||
|
|
\`\`\`
|
|||
|
|
|
|||
|
|
## 3. 核心决策点解析
|
|||
|
|
|
|||
|
|
### 3.1 为什么是 Next.js 而不是纯 React？
|
|||
|
|
- **SEO 是命脉**：我们的文章需要被百度、谷歌收录，纯 React 是客户端渲染 (CSR)，爬虫抓不到内容。Next.js 的服务端渲染 (SSR) 完美解决这个问题。
|
|||
|
|
- **首屏速度**：SSR 直接返回 HTML，用户不用等 JS 下载完就能看到字，体验极佳。
|
|||
|
|
|
|||
|
|
### 3.2 为什么用 Shadcn UI？
|
|||
|
|
- **不是库，是代码**：Shadcn 不是 npm 安装的包，而是把代码下载到你的 `components/ui` 目录。
|
|||
|
|
- **魔改自由**：我想把按钮改成圆的、扁的，直接改代码就行，不受第三方库的限制。这非常符合我们“独立自主”的创业精神。
|
|||
|
|
|
|||
|
|
### 3.3 为什么现在还是文件系统？
|
|||
|
|
- **奥卡姆剃刀**：如无必要，勿增实体。
|
|||
|
|
- **现状**：文章都在 Git 里，Git 就是最好的版本控制数据库。
|
|||
|
|
- **未来**：等文章超过 1000 篇，或者需要全文检索时，再把 Markdown 导入 MongoDB。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
**卡若说：**
|
|||
|
|
技术选型没有“最好”，只有“最合适”。这一套架构，扛个百万日活没问题，够我们折腾好几年了。
|