「我们共用一个密码」
共享账户并非主动选择，而是工具未提供其他方案时的无奈残留。它短期内运行良好，但总在最糟糕的时刻暴露代价。
带来三项机械性后果：第一，为移除某位成员的访问权限，必须重置所有人的密码——这意味着员工离职当天，整个团队需重新同步登录信息，而这恰恰是你最不想处理此事的时候；第二，无人能回答「这行数据是谁修改的？」，因为系统眼中所有人都是同一个身份；第三，无法实现部分权限开放——仅需查看某个数字的人员，与负责开票的人员拥有完全相同的操作权限。
因此核心问题并非戏剧化的「安全防护」——毕竟一个面向十五人的应用通常并无外部攻击风险。，而是「不可逆性」：共享账户无法拆解，只能整体替换；拖延越久，替换成本越高。
- 移除一人权限 = 重置全员密码。
- 无法回答「谁做了这件事？」：单一账户，单一身份。
- 无只读访问：查看与编辑享有同等权限。
三种角色，及其精确边界
只要应用启用登录机制，便会内置真实独立账户与三类角色。角色数量精简是刻意为之：若权限体系无法一目了然，就必然被错误配置。
管理员拥有全部权限，并独享账户管理权——可创建、停用账户及重置密码；普通用户可在应用内开展日常工作——增删改查数据，但完全不可见账户管理界面；只读角色仅限查阅——可自由浏览所有页面、打开详情页、查看仪表盘，但无法执行任何写入操作。
关键不在角色列表本身，而在于拒绝逻辑的落点。对只读角色而言，限制并非简单隐藏界面上的按钮：所有写入请求均在抵达路由前即被中间件拦截并返回 403 状态码。隐藏按钮可通过键盘快捷键或开发者工具绕过；而前置拒绝则无法规避——这正是「界面仅作提示」与「应用切实拦截」的区别。
角色信息存储于签名会话 Cookie 中，使每次请求无需查询数据库即可完成权限校验。无有效会话的访客则无法通过任何路径：页面自动跳转至登录页并记录原目标地址，API 请求则统一返回 401 状态码。
- 管理员——全权限，外加账户管理。
- 普通用户——可增删改查数据；不可访问账户管理。
- 只读角色——可浏览与查阅；所有写入请求在路由前以 403 拒绝。
- 无会话状态——API 返回 401；页面跳转至登录页。
开通账户：用户名、角色、一次性临时密码
创建账户仅需三项信息，且均不涉及邮箱地址。管理员输入用户名（2–31 位字符：字母、数字、点号、短横线、下划线）、指定角色，系统将自动生成临时密码。
该密码仅在创建时显示一次，此后不可再次查看——既不会出现在账户列表中，也不会以明文形式留存于任何位置，仅保存其哈希值。若密码在传递前丢失，管理员可随时重新生成（耗时约十秒）。此外，新账户默认标记为「首次登录须修改密码」，即用户必须在首次登录时自行设定新密码，因此管理员无法获知同事设定后的密码。
系统不发送任何邮件，此设计需提前知晓：应用本身未集成任何邮件服务。用户名与临时密码须由管理员通过自有渠道（如即时通讯、电话等）人工传递。更实际的制约在于——不存在自助式「忘记密码」流程：密码丢失者必须联系管理员重置。
首个账户随应用一同创建：用户名为「admin」，初始密码为「admin」，且同样强制要求首次登录时修改。这是一个启动引导密码，而非正式密码——系统将阻止你继续使用它。
- 用户名 + 角色：管理员仅需填写这两项。
- 临时密码由系统生成，仅显示一次。
- 首次登录强制修改密码——此后管理员无法得知该密码。
- 无邮件服务：密码传递与重置均由管理员人工完成。
关闭账户访问，同时保留完整历史记录
账户不被删除，而是被停用——且可随时恢复启用。这并非技术取巧，而是与数据回收站同源的设计判断：永久删除一条记录，将连带抹去所有关联数据；而这一损失往往数月后才被察觉——当你试图查找某条已消失的信息时。
代码中设置了两项明确拒绝逻辑，防止你意外锁死自身：禁止停用当前登录账户——这是清理账户列表时最易误触的操作；禁止停用最后一个活跃管理员——无管理员的应用意味着再无人能开启任何账户（包括你自己）。该拒绝逻辑显式抛出提示，而非静默失败。
因此，员工离职只需一步操作：停用账户，既不影响他人密码，也不破坏历史痕迹；人员替换则分两步：先停用旧账户，再新建账户。
- 可逆停用，而非永久删除。
- 禁止停用当前登录账户。
- 禁止停用最后一个活跃管理员。
- 管理员可随时重置任意账户密码。
它做不到的事，提前知晓更有价值
权限作用域为全局级别。每个账户绑定单一角色，该角色不与任何实体、模块或字段产生关联。因此，无法表达诸如「该销售仅可见其名下客户」「此人可访问工单但不可访问开票」「该字段对非管理层隐藏」等精细化策略。三种角色能很好回答「能否查看或修改」这个问题，但完全不回答「能查看或修改哪一部分」这个问题。
应用仅记录数据「何时」变更，从不记录「何人」变更。每条记录自动包含创建时间与最后修改时间，但无作者字段。独立账户解决了「谁能进入」的问题，却未解决「谁写了这行」的问题——二者本质不同，而本产品仅处理前者。这是最容易被误认为已支持的功能，因为拥有独立账户容易让人误以为系统能追踪到每次修改的具体执行人。
登录方式仅支持用户名+密码，不支持其他途径：无 Google/Microsoft 账户登录、无企业级单点登录（SSO）、无二次验证。对于已在其他平台统一管理身份的团队，这意味着需额外维护一份账户清单。
这四项限制并非疏漏，而是产品交付范围的明确边界。主动阐明它们，远胜于让用户自行踩坑。它们共享同一解决方案——这也是本产品的核心价值：应用源代码完全归属你。它是一个标准 Next.js 与 Prisma 项目，可导出 ZIP 包或推送至你的私有代码仓库：添加作者字段、按团队划分数据权限、集成企业认证等，均为常规开发工作——代码由你掌控，且任何供应商都无法拒绝你的定制需求。若数据隔离是业务本质要求，请在初始描述阶段即明确界定——正是你的文字定义了实体及其关联关系。
- 全局权限：不支持按实体、模块或字段进行权限隔离。
- 记录修改时间，不记录修改人。
- 仅支持用户名+密码：无 SSO、无第三方登录、无二次验证。
- 统一解决方案：代码归你所有，此类扩展属于常规开发。