我第一次接触商城系统的时候，其实并没有什么“自研执念”。
相反，那时候我的想法非常朴素：
有现成的，就别自己写。
市面上已经有这么多成熟的商城系统了，不管是开源的、商业化的，还是 SaaS 化的，看起来都比自己从零搞一套要省事得多。
至少在一开始，我是这么认为的。
一、最早的时候，我并不排斥现成商城系统
在前面的项目里，只要涉及商城需求，我的第一反应通常是：
- 看看有没有合适的现成系统
- 评估能不能在它的基础上做二开
- 尽量缩短交付周期
从“交付效率”的角度看，这个选择完全合理。
而且坦白说，很多商城系统本身并不差：
- 功能覆盖面很广
- 常见业务场景基本都有
- Demo 看起来也跑得挺顺
如果只是“把商城跑起来”，它们确实能解决问题。
二、真正的问题，往往出现在“要开始改”的时候
让我慢慢开始产生怀疑的，并不是这些系统“不能用”，
而是当项目进入二次开发阶段之后。
每一次真正开始动手，我都会遇到类似的问题：
- 需要先花不少时间去熟悉整个系统
- 要搞清楚哪些模块能改，哪些最好别动
- 有些逻辑明明不太合理，但又牵扯面很大
这时候，我心里其实是有点犹豫的。
因为你会逐渐意识到一件事：
你不是在“改业务”，而是在“适应系统”。
三、二次开发的成本，往往被低估了
从外面看，二次开发好像只是：
在原有系统上加点功能，改点逻辑
但真正做起来，成本往往集中在这些地方：
- 理解原系统的设计前提
- 搞清楚历史代码的来龙去脉
- 判断“这样改会不会影响别的地方”
很多时间，其实不是花在写代码上，
而是花在不敢轻易下手上。
更让我不安的是，有些设计你很难判断：
- 它是业务必然
- 还是当初为了赶进度的妥协
但无论是哪一种，你都得一起承担。
四、我开始意识到：很多修改是在“将就”
在几个项目之后，我慢慢意识到一个事实：
很多二开的过程，其实是在顺着现有结构将就需求。
表现出来大概是这样：
- 为了少动核心代码，把逻辑塞到边缘模块
- 为了复用已有功能，用不太合适的方式“绕”
- 为了避免影响升级，把一些判断写得很隐晦
单看每一次修改，其实都说得过去。
但累积起来，系统会越来越难改，然后成为屎山。
有时候连自己都会开始犹豫：
这段逻辑，为什么会写在这里？
五、让我警觉的，并不是“写得累”
真正让我开始警觉的，并不是工作量大，
而是一种越来越明显的不确定感：
- 改一个功能，需要反复确认有没有副作用
- 新需求讨论时，很难快速判断“该放在哪”
- 有些问题，只能用“原系统就是这么设计的”来解释
这时候我开始意识到：
问题可能不在某一个实现细节，而在系统整体的可控性。
六、当系统不是你自己的，很多决定都会变得被动
在现成商城系统上做二开，还有一个现实问题：
你必须接受它原本的很多前提。
比如：
- 模块是这样拆的
- 数据结构是这样定的
- 某些流程就是这么走的
即使你心里觉得“如果让我重新来，我可能不会这么做”，
但在二开的前提下，这些判断已经没有意义了。
你只能在既定结构里不断权衡、取舍、妥协。
七、怀疑，是从这里开始的
也正是在这些经历之后，我开始认真地问自己一个问题：
如果后面还会不断遇到类似的需求，我要一直这样改下去吗？
我并不是否定现成商城系统的价值，
它们在很多场景下依然是非常高效的选择。
但我开始怀疑的是：
把“长期演进”和“持续交付”的责任，建立在一个我无法完全掌控的系统之上，是否合适。
写在最后
这篇文章，并不是为了得出什么结论。
它只是记录了一个变化发生的过程：
从“现成系统优先”，到开始意识到它在某些场景下的局限。
后面的选择，其实正是从这种不安感中一步步发展出来的。
下一篇要不要写、写什么，其实并不重要。
重要的是，这个怀疑本身，是真实发生过的。
