私有全栈项目如何脱敏展示

私有项目不能靠截图堆砌。更有效的方式是先说明哪些数据不能公开、哪些流程必须脱敏、哪些系统组件仍然可以描述。

这样做的结果是，读者会先理解约束，再判断工程复杂度。

如果仓库不能公开，就用订单状态机、后台模块划分、支付回调、聊天、定时任务和 Docker 部署来证明系统完整性。

作品集里真正重要的不是把每一行代码给出去，而是让别人看出你确实把系统交付到了可运行状态。

私有产品尤其需要可追踪的业务痕迹，比如订单事件、操作记录、状态变更和风控提示。

这些信息不一定要对外暴露全部细节，但它们能说明系统不是黑箱。

审计痕迹的价值在于复盘：谁触发了什么动作、系统为什么进入下一个状态、AI 是否参与、是否需要人工确认。脱敏后展示这些设计，比展示一张后台截图更有工程含量。

私有项目最容易写成“负责前后端开发、完成支付和部署”，这种描述很难让人判断能力边界。更好的方式是列出系统模块、关键状态、异常路径和验证方式。

比如支付不是一句“接入微信支付”，而是下单、预支付、回调验签、订单状态更新、失败重试、对账和退款边界。聊天也不是“实现 WebSocket”，而是连接鉴权、消息持久化、未读状态和断线处理。

不能公开代码不等于不能公开工程判断。真正应该保护的是用户和业务数据，不是项目结构本身。

我会保留架构、流程、状态机、测试范围和部署方式，去掉真实用户、订单、支付凭据、内部配置和业务敏感规则。

这样做既不会泄露项目，又能让读者看到系统复杂度。对私有全栈项目来说，这是比“源码暂不公开”更负责的展示方式。

如果一个私有项目能把这些边界说清楚，它仍然可以成为作品集里的强证据。