DeskcommCRM 这个名字，说实话最初只是我随手起的内部代号。当时团队里客户资料散落在 Excel、微信聊天记录和几个人的大脑里，每次周会核对客户进度都要来回翻聊天记录，谁跟进了、谈到哪一步了、上次报价是多少，全靠大家自觉。我花了一个周末调研市面上的免费 CRM，要么是功能看着齐全但关键模块要付费解锁，要么数据存在别人服务器上，总觉得不踏实。后来决定自己基于现成的后台管理脚手架搭一套团队 CRM 系统，就叫 DeskcommCRM。这套系统核心就解决三件事：客户信息统一录入、跟进过程完整留痕、团队成员权限分明。今天这篇就是把整个选型、开发、部署、上线过程整理出来，给同样在纠结“自己搞还是买现成”的团队一个参考。
1. DeskcommCRM 想解决什么问题
1.1 客户信息散落在 Excel 和微信里的混乱时代
在没有统一 CRM 之前，我们团队大概有六七个销售和交付同事，每个人的客户名单都是自己维护。有人用 Excel，有人直接记在手机备忘录里，还有人是加了微信之后全靠聊天记录回忆客户需求。表面上看起来没什么大问题，实际上每逢月底汇总数据就是一场灾难：
- 同一个客户被两个人同时跟进，互相不知道对方已经报过价；
- 新同事入职之后，老客户的历史沟通记录完全不透明，交接要花一两周；
- 管理层想统计这个月新增了多少客户、成交了多少、流失了多少，没人能给出准确数字。
我自己就遇到过一件事：一个客户两周前已经明确表示暂缓采购，结果另一位同事不知道，又给对方发了产品资料，客户直接回复“你们内部是不是没有沟通过”。这种尴尬不仅影响专业形象，更直接影响客户对公司的信任度。
DeskcommCRM 要解决的第一个问题，就是把分散在各处的客户信息集中到一个永久在线的系统里。所有人看到的都是同一份数据，谁新增了客户、谁修改了跟进状态、谁上传了新的附件，系统里一目了然。
1.2 团队协作中的信息孤岛与跟进断档
信息分散的另一个后果是跟进断档。销售同事请假或者离职以后，他手上的客户基本等于无人接管。交接文档写得好一点，还能留下联系方式；写得随意一点，客户关系就断了。而且客户跟进本身是一个长周期过程，今天打了一次电话，下周发一封邮件，下个月再约一次演示，中间没有一个结构化记录的话，很容易出现“感觉聊得不错，但已经三周没联系”的情况。
我想要的系统，不是一个简单的通讯录，而是能给每个客户生成一张“生命周期卡片”。从首次接触到商机跟进，再到合同签订、售后回访，每个节点都有对应的时间记录和内容记录。这样无论是谁接手这个客户，打开系统就能看到完整的来龙去脉，不需要摸着石头过河。
1.3 为什么最终决定自建而不是直接买 SaaS
在决定自建之前，我认真试过几款市面上常见的免费 CRM，也了解了一些付费产品。结论是：免费 SaaS CRM 适合业务模式非常标准的团队，而我们是典型的非标准流程团队。
免费版本的限制通常集中在几个方面：自定义字段数量有限，业务流程想微调但没有权限改，数据量上来之后要升级套餐才能继续用，最重要的一点是数据主动权不在自己手里。对于我们来说，客户数据是核心资产，把数据长期放在第三方平台上，从长期看不确定性太高。
自建一个 CRM 确实要花时间，但好处也很直接：数据在自己服务器的数据库里，字段想怎么加就怎么加，权限规则按团队实际需要写，不需要迁就某个产品的固定设计。如果你所在团队的客户管理流程也是“有点特殊”的，那自建这条路值得认真考虑。
2. 技术选型：从零开发还是站在脚手架上
2.1 后端与前端的技术组合
DeskcommCRM 的技术栈选型，我一开始就定下了“尽量用成熟方案，不做技术发明”的原则。客户管理系统没有特别复杂的并发场景，核心是业务逻辑清晰、数据关系准确、长期维护方便。
后端采用 Spring Boot，原因是团队里大部分开发同事都熟悉 Java 技术栈，招聘成本低，生态成熟。数据库选了 MySQL 8.x，在单表数据量百万以内的情况下，配合合理索引完全够用。前端部分用的是 Vue 3 + Element Plus，原因是后台管理系统用这套组合非常成熟，表格、表单、弹窗这些组件开箱即用，不用自己从头写 UI。
管理体系上，我们参考了 RuoYi 这类成熟后台管理脚手架。这类项目最大的价值不是代码本身，而是它已经把用户管理、角色权限、菜单配置、操作日志、定时任务这些通用能力提前做好了。在它的基础上做 CRM 业务模块，相当于站在别人铺好的路上跑，省下的时间不是一星半点。
后端：Spring Boot 3.x + MyBatis-Plus + MySQL 8.x + Redis 前端：Vue 3 + Vite + Element Plus + Pinia 权限：Spring Security + JWT 部署：阿里云 ECS + Nginx + Certbot 自动续期证书2.2 数据库设计：客户、联系人、商机、跟进记录四大核心表
CRM 系统说到底是围绕“客户”和“关系”转的。DeskcommCRM 的表结构设计，核心是四张业务表：
客户表（customer）存的是公司维度的基本信息，包括公司名称、统一社会信用代码、行业分类、客户来源、所属销售、客户状态（潜在/意向/成交/流失）等。
联系人表（contact）与客户表是多对一关系，因为一家公司通常有多个联系人——技术负责人、采购负责人、决策人，每个人关注点不一样，必须分开记录。
商机表（business_opportunity）记录的是具体的销售机会，包括预计成交金额、所处阶段（初步沟通/方案确认/商务谈判/已成交/已流失）、预计成交日期。
跟进记录表（follow_record）记录每次与客户互动的详情，包括跟进方式（电话/邮件/上门/微信）、跟进内容、下次跟进时间。这张表是整个系统里数据量增长最快的一张表。
设计时特别注意一个细节：所有关联字段都要建索引。客户姓名、所属销售、跟进日期这些高频查询条件，不加索引的话数据量到几万条时就会明显变慢。我自己在初版，就因为忘记给 follow_record 表的 next_follow_time 加索引，导致按月查询的时候查询时间飙升到两三秒，后来补上索引立刻降到毫秒级。
2.3 权限模型：从粗粒度到细粒度的演变
团队规模小的时候，权限做得太复杂反而碍事。DeskcommCRM 的权限模型一开始很简单：管理员和自己。后来人多了，才逐步扩展成现在三级模型：
- 管理员：所有客户数据可见可编辑，可以配置系统参数、邀请员工、重置密码；
- 部门经理：本部门全部客户数据可见，可以查看本部门所有成员的跟进记录和业绩统计；
- 普通成员：只能看到“我负责的客户”和自己创建的客户，归属字段为空或归属别人的客户不可见。
这样的权限设计花了三天时间改了两版才定下来。第一版想做到行级权限（每个客户可以指定多个人可见），结果发现维护成本极高——每个客户都要手动配置可见范围，没人愿意做这件事情。最终退回到“按角色定归属”的粗粒度模型，虽然灵活度少了，但真正用起来了。权限设计不是越细越好，够用且愿意用，才是标准。
3. “永久在线”不是功能，是部署方案
3.1 云服务器与进程守护：让服务 7x24 小时可用
很多人在本地开发完项目就完事了，但真正的“永久在线”是从部署这一步才开始的。我自己在初版就是放到自己的电脑上跑，结果一次断电加上硬盘故障，数据差点全部丢失。后来老老实实买了一台云服务器，配置不算高，2 核 4G，但对于一个几十人团队使用的 CRM 来说完全够用。
部署进程中有一个容易忽略的关键点：进程守护。Spring Boot 打包成 jar 之后直接跑java -jar desks.jar看起来没问题，但只要服务器重启或者进程异常退出，服务就挂了，需要人手动启动。我使用 systemd 来解决，写一个 service 配置文件，把服务注册成系统守护进程，这样开机自启、崩溃自动重启就都解决了。
[Unit] Description=DeskcommCRM Server After=network.target [Service] Type=simple User=admin ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/deskcomm/deskcomm.jar Restart=always RestartSec=5 [Install] WantedBy=multi-user.target配置完之后执行systemctl enable deskcomm，以后即使服务器整体重启，CRM 也会自动跟着起来，这才是真正意义上“永久在线”的起点。
3.2 域名、HTTPS 与反向代理：把内网工具变成团队入口
服务跑起来了，但团队成员不可能是通过 IP 加端口的方式每天访问系统。一是难记，二是浏览器会提示不安全，三是工作场景下 HTTPS 是基本要求。
我在前面加了一层 Nginx 反向代理，同时用 Certbot 申请了免费的 SSL 证书并配置自动续期。配置完之后，团队成员在任意浏览器输入crm.公司域名.com就能打开登录页，公司名下的子域名，看起来也正式得多。
Nginx 配置里有一个容易被忽略的细节：前后端分离项目涉及两个服务的代理转发。前端静态文件由 Nginx 直接托管，后端 API 请求通过/api前缀转发到 Spring Boot 的 8080 端口。如果不做前缀区分，前端和后端的路由就会冲突。
location / { root /var/www/deskcomm; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }3.3 备份策略：永久在线的另一面是数据安全
说句不好听的，很多人只想着 CRM 一直能访问，却不想数据万一丢了怎么办。“永久在线”等于“数据永远安全”——这个等式不成立。服务器被误删、磁盘损坏、人为误操作删库，这些都是真实存在的风险。
我现在的备份策略分三层：
- 每日全量备份：每天凌晨 2 点用 cron 执行 mysqldump 备份全部数据库，保留最近 7 份；
- 异地备份：本地 NAS 每天从云服务器拉取备份文件，防止云厂商出现问题导致数据永久丢失；
- 每月恢复演练：每个月把备份文件恢复到一台临时测试机上验证可用性，确保备份不是一堆没用的文件。
第一版的备份策略只有一条：mysqldump 备份后留在服务器本地。直到有一次磁盘满了导致备份失败，还没人发现，我才意识到备份的一个原则——没有验证过的备份等于没有备份。恢复演练虽然麻烦，但这是唯一能让“永久在线”站得住脚的底线。
4. 核心功能落地：客户全生命周期管理
4.1 录入与去重：上线第一天就被重复客户数据打脸
系统上线第一天，大家还比较积极，当天录入了上百条客户数据。第二天我跑了一条统计 SQL，发现同一家公司出现了三次，只是每次录入的行业、地址写法不完全一样。客户去重是 CRM 系统里比想象中更重要的问题——没有去重机制，时间长了系统会变成另一堆混乱的数据，只不过从 Excel 搬进了服务器。
我的解决方案分两步。第一步在录入时做模糊查重：用户输入客户名称时，前端实时请求后端做相似度匹配，把名称相似的客户列出来，提醒用户确认是否已存在。第二步是建立一个简单的清洗定时任务：每周扫描一次客户表，对名称相似度高于阈值的记录进行标记，由管理员人工合并。
这个方案不算完美，偶尔也会出现“明明重复了但没有提醒”的情况。但实际用下来，系统里的重复率从最初的百分之十几降到了百分之三左右，已经达到可接受的范围。
4.2 跟进记录与商机阶段：把销售过程变成可追溯的流程
CRM 比通讯录多出来的核心能力，就是跟进记录。DeskcommCRM 里设置了一条强制规则：每次给客户打电话、发邮件或者上门拜访之后，必须在当天把跟进内容写进系统。这个规则一开始有人觉得烦，觉得业务都做完了还要花时间填表，但在坚持执行两个月之后，大多数人都体会到了好处：下次联系客户前花一分钟看一下历史记录，就能立刻接上话头，不用再问“上次聊到哪里了”。
商机阶段上，我结合团队习惯定义了六个阶段。这套设计的价值在于，管理层能随时看到整个团队的销售漏斗——有多少商机在初步沟通阶段、有多少进入方案确认阶段、预计成交金额总量是多少。每次周会不用再听个人汇报“我感觉快成了”，直接看系统里的阶段数据，哪些商机推进得慢一目了然。
我发现一个特别值得说的细节：下次跟进时间一定要做成必填字段。系统首页会显示“今天需要跟进的客户”列表，销售每天早上打开系统就知道今天该给谁打电话。没有这个字段，跟进记录就容易沦为流水账，对实际业务推动没有帮助。
4.3 统计报表：老板真正想看的三个数字
脚手架自带的统计功能非常弱，CRM 业务又强依赖数据汇总，所以报表模块完全是自己开发的。实际开发中，我没做花哨的可视化大屏，只做了三个最实在的数字：
- 本月新增客户数——判断市场活动的获客效果；
- 本月成交金额——团队业绩的直接反映；
- 本月跟进次数——衡量每个人对存量客户的维护力度。
报表页面默认展示这两个月的趋势对比，昨天数据和本月累计并排显示。对于规模不大的团队来说，这三个指标比任何复杂模型都实用。报表数据的 SQL 其实很简单，但有一个隐藏难点是时区问题——数据库时区和应用服务器时区不一致，会导致“昨天”的统计结果每隔几天就偏差一次。这个问题在部署章节之外专门提一下，是因为踩坑过程太痛苦了，后面会细说。
5. 团队在线协作：员工邀请与权限边界
5.1 邀请员工加入系统的完整流程
从应用场景来说，DeskcommCRM 最终要承接的第一个动作，就是让团队成员能够顺利加入系统，开始往里面录客户、记跟进。我参考了不少同类产品的设计思路，最终定了一条最简单的流程：管理员在后台生成邀请码 → 成员用邀请码自行注册 → 管理员在后台确认角色归属。
具体的操作路径如下：
- 管理员登录后进入“系统管理-成员管理”，点击“邀请员工”；
- 系统弹出一个输入框，填写被邀请人的姓名，然后生成一个 6 位邀请码和一条邀请链接；
- 成员打开这个链接，输入自己的手机号、姓名和工作邮箱，提交之后系统自动跳转登录页；
- 管理员在后台的待审核列表中确认对方身份，分配角色（普通成员/部门经理/管理员）；
- 成员用手机号和设置的密码登录，即可开始使用。
这个流程比直接由管理员创建账号多了一步确认手续，但好处是员工入职时可以自行完成注册，管理员不需要挨个收集身份证信息、设置初始密码。邀请码的有效期我设置了 48 小时，超过时间自动失效，避免邀请链接被转发滥用。
5.2 角色权限：哪些人能看到全部客户，哪些人只能看自己的
权限这个问题，我是在系统用了两个月之后才认真面对它的。一开始为了效率，所有人都给了管理员权限，整个系统里所有客户数据对所有人可见。当时觉得团队内部氛围好，无所谓。但后来出现了一个不愉快的场景：销售 A 辛苦跟进了一个客户大半年，结果另一个同事通过后台导出客户名单，绕过 A 直接联系了客户。虽然最后解释清楚了，但这个事件让我下定决心要严格权限管理。
现在 DeskcommCRM 的访问控制是基于角色的：
| 功能模块 | 普通成员 | 部门经理 | 管理员 |
|---|---|---|---|
| 查看自己负责的客户 | 可用 | 可用 | 可用 |
| 查看部门全部客户 | 不可用 | 可用 | 可用 |
| 查看全公司客户 | 不可用 | 不可用 | 可用 |
| 新建/编辑客户 | 可用 | 可用 | 可用 |
| 删除客户 | 仅限自己创建 | 本部门可删 | 全部可删 |
| 导出客户名单 | 仅限自己数据 | 本部门数据 | 全部数据 |
| 邀请员工 | 不可用 | 不可用 | 可用 |
这个表格反映的是最终版本。初版我做了非常复杂的“客户共享池”概念，想把公海客户、私海客户、临时共享几个场景都做进去，结果开发周期拉长一倍，而且业务方根本分不清这些概念。后来砍掉了绝大部分，表的形态变成现在这样子，大家用起来反而没有歧义。权限的粒度要把控在“一个普通人不需要动脑就能理解”的范围内。
5.3 操作日志：数据能追溯，甩锅不再有争议
任何一个团队管理系统，如果只是业务数据完整但操作过程不可追溯，迟早会有说不清的状况出现。DeskcommCRM 在脚手架自带的操作日志基础上，额外记录了三个维度的信息：
- 客户基本信息的每一次修改，保留修改前后的值对比；
- 跟进记录的每一次删除，不直接物理删除而是标记为已删除状态，管理员可见；
- 任何导出操作都记录操作人、导出时间、导出范围。
有了这套日志体系之后，团队里再也没有“我没改过这个客户的状态啊”“这个客户的数据怎么不见了”之类的争论。有事直接拉日志，谁做了什么、什么时间做的、改动前后数据是什么样，一目了然。这个功能没有花哨的技术含量，但我觉得是整个系统里团队认可度最高的模块之一。
6. 免费自部署与商业 SaaS 的取舍：我的真实体会
6.1 数据归属与迁移自由度
当初调研的时候，我发现很多免费 CRM 产品存在一个共同现象：免费版的数据导出能力是受限的。有的产品只能导出 CSV，但关键字段缺失；有的产品每月只能导出一部分数据；更有甚者，账号过期之后连数据都登录不进去。这些限制本身可能写得清清楚楚，但对于创业团队来说，一旦客户数据积累到几千条，再想换系统，迁移成本已经高到无法承受。
自部署的 DeskcommCRM 全部数据都在自己的 MySQL 数据库里，直接导出 SQL 文件或者 CSV，随时可以完整迁移到其他平台。数据就是裸数据，没有任何功能锁定。这一点在选型时需要想清楚：免费的 SaaS CRM，真正的代价是你的数据主动权。
6.2 二次开发成本与长期维护
自部署的核心优势是定制自由。以我们团队为例，上线三个月后提了一个需求：客户来源字段里需要一个“转介绍”选项，并且要在客户详情页自动展示介绍人信息。这个需求在 SaaS CRM 里要么是付费版本才有的高级功能，要么根本不支持。但自己维护的系统里，就是一个字段加一个页面组件的事情，当天就开发上线了。
被很多人忽视的是自部署的长期维护成本。服务器是笔长期支出，虽然不大，但每年都在发生；部分安全补丁需要定期更新；团队成员离职后需要及时清理账号；数据库膨胀之后需要做数据清理和归档。这些工作虽然不是天天都有，但确实是一种持续的技术债。如果你所在团队没有一位能花时间去维护自建系统的人，那建议还是认真考虑商业 SaaS 产品。
6.3 什么时候应该老老实实用 SaaS
自建不是所有场景的最佳答案。我在实际落地过程中总结了一个判断标准：如果团队客户量大、地域分散、销售团队高度移动办公，那么一套移动端体验完善的 SaaS CRM 带来的价值，远远超过数据和定制带来的收益。SaaS 产品在移动端的投入通常远大于自建项目，纯 Web 的自建系统在手机上的使用体验很难和原生 App 相比。
反过来，如果团队规模不大、业务模式还在持续调整、希望客户数据完全掌握在自己手里，那自建一个 DeskcommCRM 这样的轻量系统，是成本可控并且长期收益不错的选择。它不会替代所有 SaaS CRM，但“自己的地盘自己做主”这个优势在很多场景下是不可替代的。
7. 踩坑记录：部署和上线过程中的真实教训
7.1 时区问题：数据库和 Java 进程的时间不一致
第一个比较隐蔽的问题是时区。MySQL 连接串里的serverTimezone参数必须设置。我第一次配置数据库连接时用的是默认配置，结果系统显示的时间和实际时间相差了八小时——用户当天创建的数据，到了第二天看却还是显示前一天的日期。
排查过程其实不难，Google 一下就能找到原因：MySQL 的会话时区默认是系统时区 UTF-8，而 Java 的默认时区是 Asia/Shanghai，两个不一致导致日期时间字段在传输过程中被转换。解决办法是统一两端的时区配置：
jdbc:mysql://localhost:3306/deskcomm?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai这个坑虽然花了我一小时排查，但好在影响范围有限，数据库里已经录入的数据只要在服务端统一时区后就自动校准了。部署前先确认所有环境变量的时区设置，能省掉很多后期的“对不上账”。
7.2 邮件通知被当垃圾邮件的处理
DeskcommCRM 里有一个简单的提醒功能：每天上午 9 点给销售发送“今日待跟进客户”邮件。这个功能做了很久，但上线后每天的退信率一直在百分之三十左右，很多同事反馈收不到邮件。查下来发现是邮件服务器发出的邮件被对方邮箱服务识别为垃圾邮件。
问题出在发送邮件的服务器 IP 没有独立的发件域名绑定。我当时的解决方案是配置了 SPF 和 DKIM 记录，把发件服务器的 IP 绑定到我们自己的域名下，并在邮件正文里去掉了过长链接和大量感叹号这类易被误判为营销邮件的内容。调整之后，退信率降到了 3 以内。
企业邮箱和垃圾邮件策略是自建系统里一个很容易被忽视的点，但团队成员的日常使用体验会直接受到它的影响。如果自建系统包含通知功能，建议在开发阶段就把邮件投递质量纳入测试范围。
7.3 忘了给上传目录做权限隔离
上线初期，客户资料模块支持上传附件，比如客户的合同扫描件、产品需求文档。当时直接使用 Spring Boot 的静态资源映射来处理上传文件，结果所有已登录用户都能通过一个 URL 猜到并下载任意附件。这在团队小、互相熟悉的情况下，还能靠自觉不出事；一旦权限边界被突破，低权限用户就能直接访问高权限用户的客户文件。
修复方式是在 Nginx 层做 URL 重写，将所有上传文件请求转发到后端一个鉴权接口，只有通过权限校验的请求才返回文件流。另外文件存储目录不再放在项目内部，而是放到一个独立的路径，由 Nginx 屏蔽外部直接访问。
location ~ ^/files/(.+) { internal; alias /data/deskcomm/upload/$1; }internal这个 Nginx 指令是这类资源保护的关键，它让外部无法直接访问 Nginx 的本地文件路径，只有通过内部重定向才能拿到文件。虽然这个坑是在一次安全自查中发现的，当时并没有发生实际泄密事件，但想起来也是后怕——客户数据隐私这种事，等到真正出事就晚了。
7.4 升级依赖引发的序列化兼容问题
开发过程中为了修复一个安全漏洞，把 Spring Boot 从 2.7 升级到了 3.x。这个升级本身是常规动作，但当我把新版本部署上去之后，发现所有之前登录过的用户都会出现“登录状态失效需要重新登录”的现象。排查了很久，最后发现是 Spring Security 的序列化机制在版本升级后发生了变化，旧版本生成的 Session 数据在反序列化时失败，导致所有会话失效。
当时团队里正好有几十条待办的跟进记录，因为大家被迫重新登录，还以为是自己记错了密码。这个教训直接促成了一条团队开发规范：生产环境的依赖升级必须提前做兼容性测试，尤其要检查序列化和反序列化逻辑。另一点是升级操作尽量安排在业务低峰期，避免所有用户在同一时间被强制登出。
7.5 备份恢复演练比备份本身重要
最后这个坑不是技术问题，是流程问题。我把自动备份配置好之后的一个月里，从没真正检验过备份文件是否可用。直到一次需要把数据恢复到测试环境时，才发现 mysqldump 的备份文件在特定字符集设置下，导入时出现了乱码问题，导致部分客户名称和备注信息变成了问号。
数据库字符集不统一是主要原因，创建表时有些表用了 utf8mb4，有些继承了默认的 utf8，导出的 SQL 文件在导入到其他库时就产生了字符集不一致。重新定义了备份脚本，统一字符集导出，并配置了字符集转换参数后，这个问题解决了。
mysqldump -u root -p --default-character-set=utf8mb4 --single-transaction --routines --triggers deskcomm > /data/backup/deskcomm_$(date +\%Y\%m\%d).sql但更重要的是我养成了一个新的习惯：每个月的备份恢复演练和实际业务一样对待，只有当测试环境能从备份文件完整恢复出一份可用的数据时，这个备份才算真正有效。从那以后，我宁可花一小时做恢复演练，也不愿意在关键时刻发现备份文件是一堆废数据。
如果在搭建 DeskcommCRM 的过程中只让我推荐一个经验的话，我会说：先解决数据统一和跟进留痕这两件最基本的事，再去折腾那些花哨的功能增强工具。客户管理工具的本质是让团队的信息流动更顺畅、决策有依据，而不是用一个更复杂的工具去模拟以前混乱的工作方式。系统跑起来才是第一步，后续还有字段调整、报表优化、权限微调这些持续打磨的路要走。DeskcommCRM 对我来说已经不只是一个项目，它更像是团队协作方式的一次重新梳理——从这中间获得的经验，比代码本身更值钱。
