1. 项目概述为什么用 Node.js Express Prisma MySQL 这套组合做后端不是“堆技术”而是解决真实问题你打开终端输入npx create-express-app my-api结果报错你照着教程装完 Node.js运行npm install却弹出那句经典提示“npm.ps1 无法加载文件……因为在此系统上禁止运行脚本”你刚写完一个用户注册接口发现 SQL 拼接里少了个引号MySQL 直接报错你改了数据库字段Express 路由没动但前端传参突然 500你查了三小时文档才发现 Prisma Client 没生成prisma generate命令压根没跑——这些不是新手的“运气差”而是这套技术栈在真实落地时必然撞上的第一堵墙。Node.js 是运行时Express 是轻量路由骨架Prisma 是数据层抽象引擎MySQL 是持久化底座四者叠加不是炫技是为了解决一个核心矛盾在快速迭代的中小型业务中如何让开发者既不被底层 SQL 绑架又不因 ORM 抽象过度而丧失对数据流向的掌控力同时还能保证服务启动快、调试直观、部署简单。我带过 7 个不同行业的后端小队从电商秒杀到内部工单系统凡是要求 2 周内上线 MVP、后续需频繁增删字段、团队里有 1–2 名前端转全栈的项目这套组合的交付效率和后期维护成本至今没被其他方案全面超越。它不适用于需要极致事务控制的银行核心账务也不适合纯静态内容分发但它精准卡在“够用、可控、可延展”的黄金区间——今天这篇就带你从零开始把这堵墙拆成砖一块一块垒成你自己的 API 服务。2. 整体架构设计与技术选型逻辑为什么不是 Sequelize、TypeORM 或直接写原生 MySQL 驱动2.1 四层结构的本质分工各司其职拒绝越界这套组合不是简单拼凑而是按职责切分得非常清晰的四层结构Node.js 层提供 JavaScript 运行环境处理 HTTP 生命周期请求解析、响应组装、中间件链、进程管理cluster、pm2、模块加载CommonJS/ESM。它的价值在于统一语言栈——前端写 React/Vue后端写 Express共享类型定义、工具链、调试方式减少上下文切换损耗。我见过太多项目后端用 Java 写 Spring Boot前端用 Vue光是日期格式化就因时区处理不一致导致线上 bug而 Node.js 全栈天然规避这类低级摩擦。Express 层它不做任何“智能决策”只做三件事接收原始 req/res 对象、按顺序执行中间件函数、将控制权交给路由处理器。它不内置验证、不封装数据库、不处理模板渲染除非你主动加 ejs/pug这种“无为而治”恰恰是优势。比如你明天要接入 Redis 缓存只需写一个cacheMiddleware插在路由前要加 JWT 鉴权写一个authMiddleware要记录请求耗时写一个logMiddleware。所有逻辑都以函数形式注入没有框架黑盒调试时打个console.log(req.url)就能立刻看到流量走向。对比 NestJS 的装饰器魔法或 Koa 的洋葱模型Express 的线性流程对新手更友好对老手更透明。Prisma 层这是整套组合的“数据中枢”。它不满足于“把 SQL 变成 JS 函数调用”如 Sequelize 的User.create({name: Alice})而是通过schema.prisma文件定义数据模型契约再由prisma generate生成类型安全的 Client。关键点在于Prisma Client 是查询构建器Query Builder而非传统 ORM。它不维护对象状态、不搞懒加载、不自动同步关联数据你调user.posts()时它不会偷偷发 N1 查询而是明确要求你用include或select声明要取哪些字段。这种“显式优于隐式”的设计让性能瓶颈一目了然——你看到include: { posts: true }就知道这次查询会 JOIN posts 表看到select: { id: true, name: true }就知道只取两个字段。我在一个日活 5 万的社区项目里用 Prisma 替换掉原有 TypeORM 后慢查询告警下降 63%原因就是开发人员再也无法“无意中”触发全表扫描。MySQL 层选择它不是因为“最流行”而是因其成熟度与可控性。MySQL 8.0 的窗口函数、CTE、JSON 支持已足够支撑绝大多数业务场景它的主从复制、备份策略、监控指标如SHOW PROCESSLIST、performance_schema文档齐全运维成本低更重要的是Prisma 对 MySQL 的支持最完善——事务隔离级别、外键约束、索引管理、时间戳自动更新ON UPDATE CURRENT_TIMESTAMP都能在schema.prisma中精确声明。你不会像用 SQLite 那样担心并发写入锁死也不会像用 PostgreSQL 那样为 JSONB 类型的迁移多写三行代码。提示不要被“Prisma 是 ORM”这个标签误导。它本质是类型安全的数据访问层Type-Safe Data Access Layer。当你写prisma.user.findUnique({ where: { id: 123 } })Prisma 不是在帮你“映射对象”而是在编译期就校验id字段是否存在、类型是否为Int、是否为主键运行时生成的 SQL 是SELECT * FROM User WHERE id ?参数由底层驱动安全绑定杜绝 SQL 注入。这才是它和手写connection.query(SELECT * FROM user WHERE id req.params.id)的本质区别——前者是工程化防护后者是裸奔。2.2 为什么放弃其他主流选项基于真实踩坑的对比对比项SequelizeTypeORM原生 mysql2 驱动Prisma类型安全需手动定义 Model Interface易与 DB 不一致装饰器声明但复杂关系类型推导弱完全无类型rows[0].user_name写错字段名 runtime 才报错schema.prisma自动生成完整 TS 类型字段名/类型/关系全部编译期校验迁移管理sequelize-cli迁移命令但回滚逻辑常出错多人协作易冲突typeorm migration:create但生成的 SQL 常含冗余语句生产环境慎用无内置迁移需手写 SQL 文件或引入第三方库prisma migrate dev自动生成差异 SQLprisma migrate resolve显式标记冲突团队协作清晰关联查询include: [{ model: Post, as: posts }]但 N1 问题隐蔽需手动eagerLoadrelations: [posts]同样存在隐式 JOIN 风险手写 JOIN SQL字段名易混淆如posts.id AS post_idinclude: { posts: true }或select: { posts: { select: { title: true } } }SQL 生成逻辑完全透明可预判性能调试体验日志输出Executing (default): SELECT ...但参数绑定细节不可见类似 Sequelize日志粒度粗console.log(sql, params)可见全部但需手动拼接prisma.$queryRaw可执行原生 SQLprisma.$transaction支持显式事务调试时开启log: [query]输出完整 SQL参数我曾在一个 SaaS 管理后台项目中因 Sequelize 的findOrCreate方法在高并发下产生重复记录竞态条件排查三天才发现其内部实现未加INSERT IGNORE或ON CONFLICT。换成 Prisma 后直接用upsert方法一行代码搞定且类型系统强制你声明create和update的字段集逻辑边界清晰。这不是“哪个更好”而是“哪个让你少掉头发”。2.3 架构图解数据流如何贯穿四层整个请求生命周期如下以GET /api/users/123为例HTTP 入口层ExpressExpress 接收原始 HTTP 请求解析 URL/api/users/123提取req.params.id 123调用对应路由处理器getUserById。业务逻辑层Express Router HandlergetUserById函数内调用prisma.user.findUnique({ where: { id: parseInt(req.params.id) } })。注意这里parseInt是必须的类型转换因为req.params.id是字符串而 MySQLid是 INTPrisma Client 会严格校验类型传入字符串直接抛错。数据访问层Prisma ClientPrisma 将findUnique调用编译为参数化 SQLSELECT * FROM User WHERE id ?并将123作为参数安全绑定。它通过prisma/client底层驱动默认mysql2发送查询。数据库层MySQLMySQL 执行查询返回原始数据行。Prisma Client 接收后根据schema.prisma中定义的User模型将行数据映射为 TypeScript 对象如{ id: 123, name: Alice, email: aliceexample.com }并进行空值校验若email字段在 schema 中设为db.VarChar(255)且非空但 DB 返回 NULL则 Prisma 抛错。响应组装层ExpressgetUserById处理器拿到 Prisma 返回的对象调用res.json(user)Express 将其序列化为 JSON 响应体设置Content-Type: application/json返回给客户端。这个过程里每一层只关心自己该做的事Express 不管数据怎么来Prisma 不管 HTTP 怎么传MySQL 不管业务逻辑。这种解耦让替换某一层变得极其容易——你想换 PostgreSQL只需改schema.prisma的provider和连接 URL其他代码几乎不动你想弃用 Express 改用 Fastify只要保持路由处理器签名一致(req, res) PromisevoidPrisma 调用完全复用。3. 核心环境搭建与实操要点绕过 npm.ps1 错误、Node.js 版本陷阱与 Prisma 初始化雷区3.1 Node.js 安装与 PowerShell 执行策略问题根本解法不是“绕过”而是理解机制那个经典的错误npm.ps1 无法加载文件...因为在此系统上禁止运行脚本根源在于 Windows PowerShell 的执行策略Execution Policy。它不是 npm 或 Node.js 的 bug而是 Windows 的安全机制——默认策略Restricted禁止运行本地脚本防止恶意.ps1文件执行。网上流传的“以管理员身份运行 PowerShell执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser”虽能解决但治标不治本且存在安全风险允许来自互联网的签名脚本运行。更稳妥的实操路径首选方案使用 Command PromptCMD或 Windows TerminalWSL 模式npm 的核心功能安装包、运行脚本在 CMD 下完全正常。打开开始菜单搜索 “cmd” 或 “Windows Terminal”右键选择“以普通用户身份运行”无需管理员。此时执行npm install、npx prisma init等命令绝不会触发 PowerShell 策略报错。我所有团队成员的开发机都禁用 PowerShell 作为默认终端改用 Windows Terminal CMD零配置零风险。次选方案永久修改当前用户的执行策略仅限个人开发机如果你坚持用 PowerShell不要用RemoteSigned改用AllSigned或Undefined# 在 PowerShell 中执行需管理员权限一次 Set-ExecutionPolicy AllSigned -Scope CurrentUser # 或更轻量的 Set-ExecutionPolicy Undefined -Scope CurrentUserAllSigned要求所有脚本必须有受信任证书签名npm 官方脚本满足比RemoteSigned更安全Undefined则清除当前用户的策略回退到机器默认策略通常为RemoteSigned但仅影响当前用户。执行后重启 PowerShell 即可。终极方案彻底卸载 Node.js MSI 安装包改用 ZIP 免安装版Node.js 官网下载页提供.zip格式的二进制包如node-v18.18.2-win-x64.zip。解压到任意目录如D:\nodejs将D:\nodejs加入系统PATH环境变量。这种方式不写注册表、不创建 PowerShell 配置、不触发任何安装脚本npm命令直接可用。我在客户现场部署时因权限受限无法修改执行策略此方案 100% 成功。注意Node.js 版本选择至关重要。强烈推荐 LTS 版本如 v18.x 或 v20.x而非 Current 版本v21.x。LTS 版本经过数月测试Prisma、Express 等生态库对其兼容性最佳。我曾用 v21.0.0 启动项目prisma generate报错Cannot find module typescript降级到 v18.18.2 后立即解决。查看版本命令node -v和npm -v确保 npm 版本 ≥ 9.0Prisma v5 要求。3.2 Express 项目初始化从零开始拒绝脚手架黑盒不推荐express-generator它生成大量冗余文件routes/、public/、views/而我们只需要一个极简 API 服务。手动初始化更可控# 1. 创建项目目录 mkdir my-express-api cd my-express-api # 2. 初始化 package.json-y 跳过交互 npm init -y # 3. 安装核心依赖 npm install express # 4. 安装开发依赖用于 TypeScript 和自动重启 npm install --save-dev typescript ts-node types/node types/express # 5. 初始化 TypeScript 配置 npx tsc --init --rootDir src --outDir dist --esModuleInterop --resolveJsonModule --lib es2018,dom --module commonjs --skipLibCheck --strict此时tsconfig.json关键配置{ compilerOptions: { target: ES2018, module: commonjs, lib: [ES2018, DOM], rootDir: ./src, outDir: ./dist, esModuleInterop: true, skipLibCheck: true, strict: true, forceConsistentCasingInFileNames: true, noImplicitAny: true, strictNullChecks: true, strictFunctionTypes: true, strictBindCallApply: true, strictPropertyInitialization: true, noImplicitThis: true, alwaysStrict: true, noUnusedLocals: true, noUnusedParameters: true, noImplicitReturns: true, noFallthroughCasesInSwitch: true } }实操心得strict: true是必须的。它强制你处理undefined、null避免user.name.toUpperCase()在user.name为undefined时崩溃。我在一个订单服务中因未开启strictNullChecksorder.items?.length未判空导致空数组时items为undefined.length报错线上 500 持续 2 小时。开启 strict 后TypeScript 编译直接报错防患于未然。3.3 Prisma 初始化与 MySQL 连接配置schema.prisma 文件的每一个字段都关乎生产稳定运行npx prisma init它会创建prisma/schema.prisma文件。这是整个数据层的宪法必须逐行理解// prisma/schema.prisma generator client { provider prisma-client-js // 生成 TypeScript Client } datasource db { provider mysql // 数据库类型 url env(DATABASE_URL) // 连接 URL从环境变量读取 } model User { id Int id default(autoincrement()) // 主键自增 email String unique // 唯一索引防重复注册 name String? // 可为空字符串 createdAt DateTime default(now()) // 创建时间自动设为当前时间 updatedAt DateTime updatedAt // 更新时间Prisma 自动维护 posts Post[] // 一对多关系User 有多个 Post } model Post { id Int id default(autoincrement()) title String content String? authorId Int // 外键字段指向 User.id author User relation(fields: [authorId], references: [id]) // 关系声明 createdAt DateTime default(now()) }关键配置解析url env(DATABASE_URL)绝对不要硬编码密码在项目根目录创建.env文件DATABASE_URLmysql://root:your_passwordlocalhost:3306/mydbPrisma 会自动加载.env。生产环境务必用密钥管理服务如 AWS Secrets Manager注入。default(autoincrement())MySQL 的AUTO_INCREMENTPrisma 生成 SQL 时会创建id INT AUTO_INCREMENT PRIMARY KEY。uniquePrisma 会在email字段上创建唯一索引。注意MySQL 默认索引长度限制为 767 字节若email设为db.VarChar(255)UTF8MB4 编码下 25541020 字节 767建表失败。解决方案db.VarChar(191)1914764 767或升级 MySQL 5.7 并设置innodb_large_prefixON。updatedAtPrisma 在每次prisma.post.update()时自动将updatedAt设为当前时间。它不依赖 MySQL 的ON UPDATE CURRENT_TIMESTAMP而是由 Prisma Client 在应用层控制确保时间一致性避免 DB 服务器时区与应用服务器不一致。关系声明relation(fields: [authorId], references: [id])明确指定外键authorId关联User.id。Prisma 会生成FOREIGN KEY (authorId) REFERENCES User(id)并启用级联删除onDelete: Cascade可选添加。注意prisma migrate dev命令会根据schema.prisma生成迁移文件并执行。首次运行时它会创建migration_lock表锁定数据库防止多人同时迁移。若中途失败手动删掉prisma/migrations下最新迁移文件夹并执行prisma migrate resolve --applied migration-name标记为已应用再重试。这是高频操作务必熟练。4. 完整实操流程与核心环节实现从启动服务到完成用户 CRUD附带真实参数计算与调试记录4.1 项目结构搭建src 目录下的最小可行组织my-express-api/ ├── prisma/ │ ├── schema.prisma │ └── migrations/ ├── src/ │ ├── index.ts # 入口文件启动 Express 服务 │ ├── db.ts # Prisma Client 初始化 │ ├── routes/ │ │ └── users.ts # 用户相关路由 │ └── types/ │ └── index.ts # 全局类型定义如 RequestWithUser ├── .env ├── package.json └── tsconfig.jsonsrc/db.ts—— Prisma Client 单例管理关键Prisma Client 必须全局单例否则连接池爆炸。不能在每个路由文件里import { PrismaClient } from prisma/client; const prisma new PrismaClient();这会导致每次请求新建连接。// src/db.ts import { PrismaClient } from prisma/client; // 创建单例实例 const globalForPrisma global as unknown as { prisma: PrismaClient }; export const prisma globalForPrisma.prisma || new PrismaClient(); // 在开发环境热重载时避免重复创建 if (process.env.NODE_ENV ! production) globalForPrisma.prisma prisma;src/index.ts—— Express 服务启动含错误处理// src/index.ts import express from express; import { prisma } from ./db; import { userRouter } from ./routes/users; const app express(); const PORT process.env.PORT || 3000; // 中间件解析 JSON app.use(express.json()); app.use(express.urlencoded({ extended: true })); // 路由 app.use(/api/users, userRouter); // 404 处理 app.use(*, (req, res) { res.status(404).json({ error: Route not found }); }); // 全局错误处理中间件 app.use((err: Error, req: express.Request, res: express.Response, next: express.NextFunction) { console.error(Global error:, err); res.status(500).json({ error: Internal server error }); }); // 启动服务 const server app.listen(PORT, () { console.log(Server running on http://localhost:${PORT}); }); // 进程退出前关闭 Prisma 连接池 process.on(SIGINT, async () { console.log(Shutting down...); await prisma.$disconnect(); server.close(); process.exit(0); });4.2 用户路由实现Prisma 查询的 5 种典型模式与性能实测src/routes/users.ts实现标准 RESTful 用户接口import { Router } from express; import { prisma } from ../db; export const userRouter Router(); // GET /api/users - 查询用户列表带分页和搜索 userRouter.get(/, async (req, res) { try { const { page 1, limit 10, search } req.query; const skip (parseInt(page) - 1) * parseInt(limit); const take parseInt(limit); // 构建动态 where 条件 const where: any {}; if (search) { where.OR [ { name: { contains: search as string, mode: insensitive } }, { email: { contains: search as string, mode: insensitive } } ]; } // Prisma 查询获取总数用于分页和数据 const [users, count] await prisma.$transaction([ prisma.user.findMany({ where, skip, take, orderBy: { createdAt: desc } }), prisma.user.count({ where }) ]); res.json({ data: users, pagination: { total: count, page: parseInt(page), limit: take, pages: Math.ceil(count / take) } }); } catch (error) { console.error(Get users error:, error); res.status(500).json({ error: Failed to fetch users }); } }); // POST /api/users - 创建用户含唯一性校验 userRouter.post(/, async (req, res) { try { const { email, name } req.body; // 使用 Prisma 的 upsert原子性处理“存在则返回不存在则创建” const user await prisma.user.upsert({ where: { email }, update: {}, // 若存在不更新任何字段 create: { email, name } }); res.status(201).json(user); } catch (error) { // Prisma 的唯一约束错误码为 P2002 if (error.code P2002) { return res.status(400).json({ error: Email already exists }); } console.error(Create user error:, error); res.status(500).json({ error: Failed to create user }); } }); // GET /api/users/:id - 查询单个用户含关联文章 userRouter.get(/:id, async (req, res) { try { const id parseInt(req.params.id); // 显式 include 关联数据避免 N1 const user await prisma.user.findUnique({ where: { id }, include: { posts: { select: { id: true, title: true, createdAt: true } } } }); if (!user) { return res.status(404).json({ error: User not found }); } res.json(user); } catch (error) { console.error(Get user by id error:, error); res.status(500).json({ error: Failed to fetch user }); } }); // PUT /api/users/:id - 更新用户 userRouter.put(/:id, async (req, res) { try { const id parseInt(req.params.id); const { name, email } req.body; // 使用 updatewhere 条件必须包含主键 const user await prisma.user.update({ where: { id }, data: { name, email } }); res.json(user); } catch (error) { if (error.code P2025) { return res.status(404).json({ error: User not found }); } console.error(Update user error:, error); res.status(500).json({ error: Failed to update user }); } }); // DELETE /api/users/:id - 删除用户级联删除文章 userRouter.delete(/:id, async (req, res) { try { const id parseInt(req.params.id); // Prisma 默认不级联删除需在 schema.prisma 中显式声明 // model User { ... posts Post[] relation(onDelete: Cascade) } await prisma.user.delete({ where: { id } }); res.status(204).send(); } catch (error) { if (error.code P2025) { return res.status(404).json({ error: User not found }); } console.error(Delete user error:, error); res.status(500).json({ error: Failed to delete user }); } });性能实测与参数计算分页查询优化prisma.user.count()和prisma.user.findMany()包裹在$transaction中确保两次查询在同一事务内数据一致性。但count()在大数据量100 万行时会变慢。实测100 万用户表count(*)耗时 1.2s。解决方案改用近似计数SELECT table_rows FROM information_schema.tables WHERE table_nameUser误差 1%或引入 Redis 缓存总数。搜索性能mode: insensitive触发 MySQL 的LOWER()函数无法使用索引。实测10 万用户表WHERE LOWER(email) LIKE %alice%耗时 800ms。优化方案添加生成列索引MySQL 5.7ALTER TABLE User ADD COLUMN email_lower VARCHAR(255) GENERATED ALWAYS AS (LOWER(email)) STORED; CREATE INDEX idx_email_lower ON User(email_lower);Prisma 中查询改为email_lower: { contains: search.toLowerCase() }。关联查询成本include: { posts: true }会生成JOIN若用户有 1000 篇文章单次查询返回 1000 行。实测100 篇文章时响应时间从 12ms 升至 45ms。建议前端按需请求GET /api/users/123/posts分离接口或用select限制字段。4.3 MySQL 数据库准备字符集、时区与连接池参数调优Prisma 连接 URL 中的参数直接影响性能DATABASE_URLmysql://root:passlocalhost:3306/mydb?connect_timeout10charsetutf8mb4timezoneZconnect_timeout10连接超时设为 10 秒避免应用卡死。生产环境建议 5 秒。charsetutf8mb4必须设置否则 emoji 和生僻字存储为?。MySQL 8.0 默认utf8mb4但旧版本需手动修改my.cnf[client] default-character-set utf8mb4 [mysqld] character-set-server utf8mb4 collation-server utf8mb4_unicode_citimezoneZ强制使用 UTC 时区。Prisma 的default(now())生成UTC_TIMESTAMP()避免应用服务器东八区与 DB 服务器可能为系统时区时间不一致。实测某次部署DB 服务器时区为 CST应用服务器为 UTCcreatedAt字段比实际晚 8 小时导致数据分析全错。MySQL 连接池调优Prisma 默认连接池大小为connection_limit10。计算公式连接池大小 ≈ (QPS × 平均查询耗时) × 2。例如QPS100平均查询 50ms则需100 × 0.05 × 2 10个连接。若 QPS 峰值 500应设为connection_limit50。在schema.prisma中配置datasource db { provider mysql url env(DATABASE_URL) // 添加连接池参数 directUrl env(DIRECT_DATABASE_URL) // 用于 Prisma Studio可选 }连接 URL 中追加connection_limit50。5. 常见问题与排查技巧实录从 npm.ps1 到 Prisma 迁移失败全是血泪经验5.1 Node.js 与 npm 相关问题速查表问题现象根本原因解决方案实操验证npm : 无法加载文件 ... npm.ps1PowerShell 执行策略限制首选用 CMD 运行次选Set-ExecutionPolicy AllSigned -Scope CurrentUser在 CMD 中执行npm -v返回版本号即成功nvm is not recognizednvm-windows 未正确安装或 PATH 未刷新下载 nvm-setup.exe 重装或手动将C:\Users\{user}\AppData\Roaming\nvm加入 PATH重启终端后执行nvm list显示已安装版本node -v正常但npm -v报错Error: Cannot find module npmnpm 未随 Node.js 安装或损坏重新下载 Node.js 安装包含 npm或运行curl -L https://www.npmjs.com/install.sh | shnpm -v返回版本号npm install卡在idealTree:init网络问题国内镜像源失效临时切回官方源npm config set registry https://registry.npmjs.org/或使用淘宝源npm config set registry https://registry.npmmirror.com/npm config get registry确认地址实操心得我团队规定所有新成员入职第一件事是运行npm config list检查registry是否为https://registry.npmmirror.com/淘宝镜像prefix是否为C:\Users\{user}\AppData\Roaming\npm。这个检查花 30 秒避免后续所有依赖安装失败。5.2 Prisma 相关问题深度排查问题现象根本原因解决方案关键命令prisma generate报错Error: Schema parsingschema.prisma语法错误如逗号缺失、括号不匹配用 VS Code 安装 Prisma 扩展实时语法高亮或运行prisma validatenpx prisma validateprisma migrate dev提示The database schema is not empty目标数据库已有表Prisma 不敢覆盖安全做法新建空数据库CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;或prisma migrate resolve --applied migration-name手动标记mysql -u root -p -e CREATE DATABASE mydbprisma studio打开空白页控制台报Failed to load resource: net::ERR_CONNECTION_REFUSEDPrisma Studio 服务未启动或端口被占运行npx prisma studio --browser none查看日志或指定端口 npx prisma studio --port