写代码时，你有没有遇到过这种情况：功能实现了，但代码像一锅乱炖，改一处地方，其他地方就出问题？或者程序跑得慢，数据一多就卡住？这时候，有人会说：‘用个合适的算法’，也有人说：‘换个设计模式’。可这两者到底是什么关系，什么时候该用哪个？
算法解决“怎么做”
算法关注的是执行效率和计算步骤。比如你要在一个名单里找某个人，最简单的方式是从头到尾一个个比对——这就是线性查找。但如果名单是按名字排好序的，用二分查找，几下就能定位到目标。
int binarySearch(int arr[], int left, int right, int target) {
while (left <= right) {
int mid = left + (right - left) / 2;
if (arr[mid] == target) return mid;
if (arr[mid] < target) left = mid + 1;
else right = mid - 1;
}
return -1;
}这个函数就是典型的算法思维：输入确定、输出明确，重点是快和准。它不管外面谁调用它，也不管状态怎么管理，只关心“如何高效完成任务”。
设计模式解决“怎么组织”
而设计模式更像是在搭积木时的结构规范。比如你在开发一个电商系统，订单状态会变：待支付、已发货、已完成。如果到处用 if-else 判断状态并执行不同逻辑，很快就会失控。
这时候状态模式就派上用场了。每个状态变成一个类，各自实现自己的行为。订单对象只需要持有当前状态的引用，运行时自动调用对应方法。
interface OrderState {
void handle(OrderContext context);
}
class PaidState implements OrderState {
public void handle(OrderContext context) {
System.out.println("订单已支付，准备发货");
context.setState(new ShippedState());
}
}这种写法让新增状态变得容易，也避免了大段条件判断。它不提升运行速度，但让代码更清晰、更容易维护。
它们不是互斥的选择
想象你在做一个地图导航应用。路径规划要用 Dijkstra 算法算出最快路线——这是算法的活儿。但整个应用的架构可能采用观察者模式：用户位置一变，地图、路线、预计到达时间多个组件自动更新。
一个是底层计算核心，一个是顶层结构组织。两者可以共存，甚至互相依赖。比如策略模式可以把不同的排序算法封装成可替换的模块，运行时根据数据规模选择快排还是归并。
实际开发中的配合
你在写一个缓存系统，LRU（最近最少使用）是个常见策略。实现它的时候，既需要双向链表+哈希表的数据结构支持（算法层面），也会用到单例模式保证全局只有一个缓存实例（设计模式层面）。
再比如，处理文件解析任务，你可以用递归下降算法来分析语法结构，同时用访问者模式把解析和后续操作解耦，方便扩展支持新格式。
很多人初学时容易混淆两者的适用场景：想优化性能却去改设计模式，结果结构更复杂了，速度一点没提；或者执着于炫技写高级算法，结果代码没人看得懂，加个新功能都得重写。
真正的高手，心里有本账：数据量大、计算密集，优先看算法；模块纠缠、频繁变更，重点用设计模式。两者都是工具，解决问题才是目的。