MVC模式真的像传说中那样松耦合吗？
很多人刚接触Web开发时，都会听到一个说法：MVC是解耦的典范。Model负责数据，View负责展示，Controller负责调度，三者各司其职。听起来很美好，但在实际项目里，真能完全做到低耦合？恐怕没那么简单。
举个常见的例子：你写了一个用户管理模块，Model里定义了User类，Controller调用它来处理请求，View则把数据显示出来。表面上看分工明确，但一旦需求变更——比如要加一个头像字段，前端要显示，后端要查数据库，接口要改——这时候你会发现，三个部分几乎都得动。
为什么看起来解耦，实际上还是牵一发而动全身？
问题出在“依赖方向”上。理想情况下，View只依赖Model的数据结构，Controller协调两者。但现实中，View常常直接调用Model的方法，或者Controller里硬编码了View的逻辑。比如下面这个伪代码：
class UserController {
public void showProfile(int userId) {
User user = userService.findById(userId);
if (user.getRole().equals("admin")) {
render("admin_profile.html", user);
} else {
render("user_profile.html", user);
}
}
}这段代码里，Controller直接决定了用哪个View模板，等于把展示逻辑写死了。如果哪天要增加一种VIP用户的页面，就得改Controller。这说明View和Controller之间依然存在强关联。
再看Model，真的独立吗？
很多项目里，Model不仅封装数据，还包含了数据库操作、校验规则甚至业务流程。比如一个User.save()方法，可能内部直接调用了JDBC或ORM框架。这样一来，Model就和数据库绑定了，换个存储方式就得重写。更别说有些View为了取数据方便，直接调用Model的save或delete，彻底打破边界。
还有种情况是View过度依赖Model字段名。前端模板里写满了user.getName()、user.getAddress()，一旦后端字段改名，页面立马报错。这种隐式契约，其实也是一种耦合。
所以说，MVC能不能做到低耦合，不在于模式本身，而在于你怎么用。框架只是画了三条线，真正走不走得到位，还得看开发者有没有意识去隔离变化。
怎么降低MVC的实际耦合度？
一个实用的做法是引入“视图模型”（ViewModel）。Controller不直接把Model丢给View，而是组装成一个专供展示的数据结构。这样即使Model变了，只要ViewModel保持兼容，View就不需要改。
另外，别让View主动去找Model。可以通过Controller传递数据，或者用观察者模式让View监听数据变化。Android里的LiveData、Vue.js的响应式数据，本质上都是在减少直接依赖。
接口定义也得讲究。比如Controller调用Service层，而不是直接操作Model；View通过统一的render方法接收数据，而不是自由访问Model方法。这些细节能一点点把紧耦合拆开。
MVC不是银弹，它提供了一种组织代码的思路，但不会自动带来低耦合。就像厨房分区合理不代表做饭就不会手忙脚乱，关键还是操作的人有没有养成好习惯。