【实战进阶(3/4) 】数据库进阶、产品设计、Bug调试、部署上线、域名配置

❌ 文件存储的问题：
- 多个用户同时写入会造成数据冲突
- 查询效率极低（需要读取整个文件）
- 无法保证数据的一致性
- 难以处理复杂的数据关系
- 数据备份和恢复困难

数据库服务器（Database Server）
  └─ 数据库（Database）
      └─ 表（Table）
          └─ 行（Row）/ 列（Column）

-- 例如，你的项目可能有：
my_app_development  -- 开发环境数据库
my_app_production   -- 生产环境数据库

-- 创建一个用户表
CREATE TABLE users (
  id SERIAL PRIMARY KEY,           -- 自增主键
  email VARCHAR(255) NOT NULL,     -- 邮箱，不能为空
  username VARCHAR(50) UNIQUE,     -- 用户名，必须唯一
  created_at TIMESTAMP DEFAULT NOW() -- 创建时间，默认当前时间
);

-- 插入一条用户记录
INSERT INTO users (email, username)
VALUES ('user@example.com', 'john_doe');

-- 插入多条记录
INSERT INTO users (email, username)
VALUES 
  ('alice@example.com', 'alice'),
  ('bob@example.com', 'bob');

-- 查询所有用户
SELECT * FROM users;

-- 查询特定字段
SELECT email, username FROM users;

-- 条件查询
SELECT * FROM users WHERE username = 'alice';

-- 排序
SELECT * FROM users ORDER BY created_at DESC;

-- 限制数量
SELECT * FROM users LIMIT 10;

-- 更新特定用户的邮箱
UPDATE users 
SET email = 'newemail@example.com' 
WHERE username = 'alice';

-- 删除特定用户
DELETE FROM users WHERE username = 'bob';

-- ⚠️ 危险操作：删除所有数据
DELETE FROM users;  -- 慎用！

-- 数字类型
INTEGER          -- 整数：-2147483648 到 2147483647
BIGINT           -- 大整数
SERIAL           -- 自增整数
DECIMAL(10,2)    -- 精确小数，适合金额

-- 文本类型
VARCHAR(n)       -- 可变长度字符串，最大 n 字符
TEXT             -- 无限长度文本

-- 日期时间
DATE             -- 日期：2024-01-15
TIME             -- 时间：14:30:00
TIMESTAMP        -- 日期+时间：2024-01-15 14:30:00

-- 布尔类型
BOOLEAN          -- true/false

-- JSON 类型（PostgreSQL 特色）
JSON             -- JSON 格式数据
JSONB            -- 二进制 JSON，查询更快

这是我要做的纸片人男友产品的SPEC，现在我要建立一个数据库，请你帮我设计一下数据库需要存储的数据内容和列表

-- 方案 1：自增整数（最常见）
CREATE TABLE posts (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL
);

-- 方案 2：UUID（分布式系统常用）
CREATE TABLE posts (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  title TEXT NOT NULL
);

-- 用户表
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  username VARCHAR(50) NOT NULL
);

-- 文章表
CREATE TABLE posts (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  content TEXT,
  author_id INTEGER REFERENCES users(id), -- 外键
  created_at TIMESTAMP DEFAULT NOW()
);

-- 学生表
CREATE TABLE students (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL
);

-- 课程表
CREATE TABLE courses (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL
);

-- 中间表（关联表）
CREATE TABLE enrollments (
  student_id INTEGER REFERENCES students(id),
  course_id INTEGER REFERENCES courses(id),
  enrolled_at TIMESTAMP DEFAULT NOW(),
  PRIMARY KEY (student_id, course_id)  -- 复合主键
);

-- 为常用查询字段添加索引
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_posts_author ON posts(author_id);

CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name VARCHAR(200) NOT NULL,
  price DECIMAL(10,2) CHECK (price > 0),  -- 价格必须大于 0
  stock INTEGER DEFAULT 0 CHECK (stock >= 0), -- 库存不能为负
  category VARCHAR(50) NOT NULL,
  
  -- 组合唯一约束
  UNIQUE (name, category)
);

第 1 周：你创建了 users 表，只有 email 和 password
第 3 周：产品经理要求添加 username 字段
第 5 周：需要添加 profile_image 字段
第 8 周：发现 email 字段长度不够，需要扩展

migrations/
  ├── 001_create_users.sql          # 第一次迁移：创建用户表
  ├── 002_add_username.sql          # 第二次迁移：添加 username 字段
  ├── 003_create_posts.sql          # 第三次迁移：创建文章表
  └── 004_add_posts_published.sql   # 第四次迁移：添加发布状态字段

你是资深全栈工程师。请先审查当前项目，然后在“现有项目”中实现一个相对完整的管理后台。不要脱离当前技术栈，不要重造数据库、认证或 API，优先复用现有结构。

核心原则：
1. 先扫描项目代码，识别当前技术栈、路由方式、UI 组件库、认证方式、数据库访问层、现有 API/Server Actions/ORM。
2. 优先复用现有页面结构、样式体系、数据库 schema、接口封装、鉴权逻辑。
3. 不要重新造一套后端；如果缺少必要接口，只补“最小必要”的管理接口。
4. 不要新增删除功能。
5. 如果现有表字段名称与我下面写的不完全一致，请基于真实 schema 做合理映射，并在最终说明里告诉我“字段映射关系”。
6. 所有管理功能都应限制为管理员可访问；如果项目里已有角色权限系统，直接复用；如果没有，请用当前认证体系补一个最小可用的 `isAdmin` 保护，并清楚标注 TODO。
7. 页面风格简洁、清晰、偏后台风格，优先可用性，不要做花哨视觉。
8. 先给出实施计划，再开始改代码。改完后告诉我新增/修改了哪些文件、路由和数据接口。

我要的后台范围：

一、后台路由结构
- `/admin`
- `/admin/users`
- `/admin/orders`

二、后台通用能力
请实现一个统一的后台布局，包含：
- 左侧导航：概览、用户管理、订单管理
- 顶部标题区
- 登录态/管理员身份校验
- 加载态、空状态、错误提示
- 简洁表格风格
- 基础分页（如果项目已有分页方案就复用，没有就做最简单可用版）
- 搜索和筛选区域
- 响应式不必做到复杂，但桌面端体验要清晰稳定

三、`/admin` 概览页
请做一个最小可用的 dashboard，总览常见运营信息。如果真实 schema 支持，就展示：
- 用户总数
- 最近新增用户数
- 订单总数
- 最近订单数
- 如果订单表里有金额字段，再展示总成交额或最近成交额
如果某些指标没有对应字段，就跳过，不要硬造假数据。

四、`/admin/users` 用户管理页
目标：
1. 展示用户列表
2. 默认展示字段：`id`、`name`、`email`、`created_at`、`status`
3. 支持按 `name` 和 `email` 搜索
4. 支持按 `status` 筛选
5. 支持分页
6. 支持编辑 `status`
7. 不要删除功能

具体要求：
- 列表使用表格展示
- 搜索框可以搜索 name/email
- 如果 schema 里 `name` 不存在，可用最接近的字段替代，如 `nickname`、`full_name`
- 编辑方式可以是弹窗、抽屉或行内编辑，但要简洁稳定
- 更新成功后刷新列表，失败时给出明确错误提示
- 如果存在用户详情页或合适的查看方式，可以增加“查看详情”，但不是必须
- 不要允许编辑敏感字段，先只改 `status`

五、`/admin/orders` 订单管理页
目标：
1. 展示订单列表
2. 优先展示字段：`id` / `order_no`、`user`、`amount`、`status`、`created_at`
3. 支持搜索订单号、用户姓名、用户邮箱（以真实 schema 能支持的为准）
4. 支持按订单状态筛选
5. 支持查看订单详情
6. 支持编辑订单 `status`
7. 不要删除功能

具体要求：
- 如果订单与用户有关联，请把用户信息通过关联查出来并展示
- 如果没有 `order_no`，可直接展示 `id`
- 如果没有 `amount`，不要硬加金额逻辑
- 订单详情里优先展示：订单基本信息、关联用户、创建时间、状态、金额、备注等真实存在的字段
- 编辑订单状态时，优先复用现有状态枚举；如果项目中已有状态流转约束，请遵守现有逻辑

六、数据访问与实现要求
- 优先使用服务端获取数据，不要把数据库密钥暴露到客户端
- 如果项目已有 API 层，就复用 API；如果项目是服务端直连数据库，也请沿用现有模式
- 查询、搜索、筛选、分页都尽量复用现有查询封装
- 不要复制一套新的 types/schema；优先复用已有类型定义
- 如果用户表、订单表已经存在关联关系，请正确使用关联查询
- 如果数据库字段命名不一致，请按实际结构实现，不要为了迎合提示词而硬改数据库

七、交付方式
请按以下顺序执行：
1. 先总结当前项目技术栈与可复用结构
2. 给出简洁的实施计划
3. 开始实现后台页面和必要接口
4. 完成后说明：
   - 新增/修改了哪些页面和文件
   - 复用了哪些现有结构
   - 用户和订单模块各自支持了哪些功能
   - 哪些地方因为真实 schema 限制做了适配
   - 下一步如果我要继续做 products、payments、logs，应该如何沿用这套后台结构

请用Next.js/Shadcn/TailwindCSS框架复刻 https://cleanup.pictures/ 
按照Section/Component，尽量拆分成为更细的Component并且放到合适的目录

{如果你再贴上cleanup.pictures的截图，就更好了}

使用pencil mcp
在当前活跃的画布上
然后重新设计「QQ音乐」手机App的所有主要界面，界面要像苹果公司的设计风格，浅色系

请根据我提供的 Stitch 导出文件，还原成一个可运行的 React 项目。

要求：
1. 包含 4 个页面：discover、now_playing、profile、search
2. 使用 React + Tailwind CSS
3. 把底部导航抽成公共组件
4. 把卡片、列表项、播放器控件等抽成可复用组件
5. 页面风格尽量和 Stitch 导出的 UI 保持一致
6. 先实现静态 UI，再补充页面切换
7. 每个页面参考对应文件夹中的 code.html 和 screen.png

{
  "mcpServers": {
    "pencil": {
      "command": "/Users/<用户名>/.trae-cn/extensions/highagency.pencildev-<版本号>/out/mcp-server-darwin-arm64",
      "args": ["--app", "trae_cn"]
    }
  }
}

使用pencil mcp
在当前活跃的画布上
然后重新设计「QQ音乐」手机App的所有主要界面，界面要像苹果公司的设计风格，浅色系

你用pencil MCP帮我修改一下人物对话页面，尽量让每个人物的对话页面都能和人物特点匹配上

我在用 Next.js 本地开发，遇到了一个报错。
报错信息如下： [粘贴报错]
我刚才做的操作是： [描述你做了什么，比如"修改了 app/api/chat/route.ts 里的一个函数"]
请帮我分析是什么原因，怎么修。

pnpm build

你在 TRAE 里修改代码
       ↓
commit + push 到 GitHub
       ↓
GitHub 触发 Webhook，通知 Vercel
       ↓
Vercel 自动拉取代码、重新构建
       ↓
新版本上线，全世界可访问

Error: OPENAI_API_KEY is not defined

NEXT_PUBLIC_TURNSTILE_SITE_KEY=你的SiteKey
TURNSTILE_SECRET_KEY=你的SecretKey

npm install @marsidev/react-turnstile

import { Turnstile } from '@marsidev/react-turnstile'

// 在表单里面，注册按钮的上方
<Turnstile
  siteKey={process.env.NEXT_PUBLIC_TURNSTILE_SITE_KEY!}
  onSuccess={(token) => {
    setTurnstileToken(token)
  }}
/>

// 从请求体中拿到前端传来的 Turnstile token
const { turnstileToken, ...registrationData } = await request.json()

// 去 Cloudflare 验证这个 token 是不是真的
const verifyResponse = await fetch(
  'https://challenges.cloudflare.com/turnstile/v0/siteverify',
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      secret: process.env.TURNSTILE_SECRET_KEY,
      response: turnstileToken,
    }),
  }
)

const verifyResult = await verifyResponse.json()

// 如果验证失败，直接拒绝
if (!verifyResult.success) {
  return Response.json(
    { error: '人机验证失败，请重试' },
    { status: 403 }
  )
}

// 验证通过，继续正常的注册流程...