Part 01｜在多个项目之后，我开始对“现成商城系统”产生怀疑

我第一次接触商城系统的时候，其实并没有什么“自研执念”。

相反，那时候我的想法非常朴素：
有现成的，就别自己写。

市面上已经有这么多成熟的商城系统了，不管是开源的、商业化的，还是 SaaS 化的，看起来都比自己从零搞一套要省事得多。

至少在一开始，我是这么认为的。

一、最早的时候，我并不排斥现成商城系统

在前面的项目里，只要涉及商城需求，我的第一反应通常是：

• 看看有没有合适的现成系统
• 评估能不能在它的基础上做二开
• 尽量缩短交付周期

从“交付效率”的角度看，这个选择完全合理。

而且坦白说，很多商城系统本身并不差：

• 功能覆盖面很广
• 常见业务场景基本都有
• Demo 看起来也跑得挺顺

如果只是“把商城跑起来”，它们确实能解决问题。

二、真正的问题，往往出现在“要开始改”的时候

让我慢慢开始产生怀疑的，并不是这些系统“不能用”，
而是当项目进入二次开发阶段之后。

每一次真正开始动手，我都会遇到类似的问题：

• 需要先花不少时间去熟悉整个系统
• 要搞清楚哪些模块能改，哪些最好别动
• 有些逻辑明明不太合理，但又牵扯面很大

这时候，我心里其实是有点犹豫的。

因为你会逐渐意识到一件事：
你不是在“改业务”，而是在“适应系统”。

三、二次开发的成本，往往被低估了

从外面看，二次开发好像只是：

在原有系统上加点功能，改点逻辑

但真正做起来，成本往往集中在这些地方：

• 理解原系统的设计前提
• 搞清楚历史代码的来龙去脉
• 判断“这样改会不会影响别的地方”

很多时间，其实不是花在写代码上，
而是花在不敢轻易下手上。

更让我不安的是，有些设计你很难判断：

• 它是业务必然
• 还是当初为了赶进度的妥协

但无论是哪一种，你都得一起承担。

四、我开始意识到：很多修改是在“将就”

在几个项目之后，我慢慢意识到一个事实：

很多二开的过程，其实是在顺着现有结构将就需求。

表现出来大概是这样：

• 为了少动核心代码，把逻辑塞到边缘模块
• 为了复用已有功能，用不太合适的方式“绕”
• 为了避免影响升级，把一些判断写得很隐晦

单看每一次修改，其实都说得过去。
但累积起来，系统会越来越难改，然后成为屎山。

有时候连自己都会开始犹豫：
这段逻辑，为什么会写在这里？

五、让我警觉的，并不是“写得累”

真正让我开始警觉的，并不是工作量大，
而是一种越来越明显的不确定感：

• 改一个功能，需要反复确认有没有副作用
• 新需求讨论时，很难快速判断“该放在哪”
• 有些问题，只能用“原系统就是这么设计的”来解释

这时候我开始意识到：

问题可能不在某一个实现细节，而在系统整体的可控性。

六、当系统不是你自己的，很多决定都会变得被动

在现成商城系统上做二开，还有一个现实问题：

你必须接受它原本的很多前提。

比如：

• 模块是这样拆的
• 数据结构是这样定的
• 某些流程就是这么走的

即使你心里觉得“如果让我重新来，我可能不会这么做”，
但在二开的前提下，这些判断已经没有意义了。

你只能在既定结构里不断权衡、取舍、妥协。

七、怀疑，是从这里开始的

也正是在这些经历之后，我开始认真地问自己一个问题：

如果后面还会不断遇到类似的需求，我要一直这样改下去吗？

我并不是否定现成商城系统的价值，
它们在很多场景下依然是非常高效的选择。

但我开始怀疑的是：
把“长期演进”和“持续交付”的责任，建立在一个我无法完全掌控的系统之上，是否合适。

写在最后

这篇文章，并不是为了得出什么结论。

它只是记录了一个变化发生的过程：
从“现成系统优先”，到开始意识到它在某些场景下的局限。

后面的选择，其实正是从这种不安感中一步步发展出来的。

下一篇要不要写、写什么，其实并不重要。
重要的是，这个怀疑本身，是真实发生过的。