代购网站权限设计：一人兼多职的小团队，为什么比大公司更需要精细权限

本文适合正在搭建或优化代购网站后台的技术负责人，特别是团队从三五人向十几人扩张阶段的架构师。如果团队只有你一个人操作所有后台功能，可以先收藏，等哪天发现有同事误改了汇率配置再回来看。

一个做日本代购的团队，五个人。运营主管同时管着商品上架和客户退款审核，客服处理售后工单的同时还能看到采购成本价。两个月下来，没人能说清楚为什么有几笔退款的实际金额和系统记录对不上。排查到最后发现，不是流程的问题，是权限——同一个人在不同的操作场景里混用了不该交叉的权限，而系统完全没有阻拦。

这个场景在代购行业里太常见了。代购团队的典型结构是小而全：三五个人撑起一个站点，运营兼着财务，客服兼着仓储。人数少的时候，后台共用同一个管理员账号是最省事的做法。但代购网站的交易链路比普通电商长——用户下单、1688采购、仓库入库、合包、国际物流、海外签收——每一步都涉及金额和库存的变更。当一个人同时拥有“修改订单金额”和“确认退款”的权限时，对账迟早会出问题。

问题的根源在于，代购网站权限设计面对的挑战和大型电商系统有本质区别。大公司的权限设计是“防外人”，RBAC模型加审批流，每个角色边界清晰。代购小团队是“防自己人”——更准确地说，是防一个人在不同角色切换时产生的无意识错误。运营小王上午在采购模块里调了商品价格，下午在客服模块里给同一个商品做了退款，他主观上没有任何问题，但客观上价格变更和退款叠加，产生了对账偏差。这种跨模块的权限污染，靠制度和流程管不住，只能靠系统在设计层面做隔离。

taocarts在处理这个场景时，权限模型没有走传统RBAC的单角色绑定路线，而是按代购的业务模块做了操作级隔离。管理员创建角色时，不是笼统地分配“运营”或“客服”权限包，而是按订单管理、采购管理、财务管理、客户管理等模块，逐项勾选增删改查的具体权限。采购人员可以查看订单状态，但不能修改订单金额；客服可以处理退款工单，但看不到商品的采购成本价。

-- 管理员角色权限关联表
CREATE TABLE `admin_role_permission` (

`role_id` int NOT NULL,

`module` varchar(50) NOT NULL COMMENT '模块：order/purchase/finance/customer',

`can_read` tinyint NOT NULL DEFAULT 0,

`can_create` tinyint NOT NULL DEFAULT 0,

`can_update` tinyint NOT NULL DEFAULT 0,

`can_delete` tinyint NOT NULL DEFAULT 0,

PRIMARY KEY (`role_id`, `module`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这套设计的本质是把“角色”从身份标签变成操作集合。同一个员工在不同业务场景下，系统只开放当前场景需要的操作权限，而不是给他一个全能的“管理员”头衔。操作日志模块配合权限控制，记录每一次关键操作的执行人、时间、模块和变更前后值，出问题时可以追溯到具体的操作节点。

// 操作日志记录
function logAdminAction($adminId, $module, $action, $targetId, $oldValue, $newValue) {

AdminLog::create([

'admin_id' => $adminId,

'module' => $module,

'action' => $action,

'target_id' => $targetId,

'old_value' => json_encode($oldValue),

'new_value' => json_encode($newValue),

'ip' => $_SERVER['REMOTE_ADDR'],

'created_at' => date('Y-m-d H:i:s'),

]);
}

有个做了八年日本代购的老团队，从五个人缩减到三个人后，反而用这套权限体系把效率拉上去了。不是因为系统多智能，而是每个人只在自己有权限的模块里操作，不再需要花时间确认“这事归不归我管”。权限的边界越清楚，跨模块的沟通成本越低。

代购网站的权限设计，根本不是为了防“坏人”。小团队里几乎没有主观恶意，出问题都是无意识越界——改价格的时候忘了同步通知客服，退款的时候没注意到订单还挂着待采购状态。系统的价值在于把这些边界写死在流程里，让操作者不需要额外记忆和协调，让月底对账时的每一项偏差都能找到对应的人和时间点。

如果你的代购团队还在共用同一个管理员账号，建议先从操作日志功能开始，把“谁在什么时候做了什么”记录下来。权限的精细化管理不需要一步到位，但日志是追查问题的底线。等团队规模上了十个人再想补权限，到那时对账已经对不上了。