电动汽车充电站选址定容优化：MATLAB+YALMIP+求解器实践

1. 项目概述与问题本质解析

电动汽车充电站优化配置，说白了就是回答两个问题：充电站建在哪儿、建多大。放在数学优化里，这就是一个典型的选址-定容问题，属于混合整数规划（MIP）的范畴。做这类项目，主流的技术路线是matlab + yalmip建模，后端接cplex或gurobi求解。我最近刚完成的一个项目就是基于这套方案做的，整体跑通之后，觉得里面有不少值得展开讲的东西，这篇就把完整思路、建模过程、求解器注意事项、以及我实际踩过的坑一并写出来。

先说清楚这个项目解决什么问题。城市里要布置一批电动汽车充电站，候选站址可能有很多个，每个站可以建设不同规模的充电桩数量（比如10个、20个、50个），但是建设成本和运营成本不一样。与此同时，电动汽车用户有充电需求，需求点分布在不同区域，每个需求点到充电站有距离成本、时间成本。我们的目标就是在预算约束、服务能力约束、电网容量约束等一系列限制下，找到最合适的建站位置和每个站的容量配置，使得总成本最低、或者用户满意度最高、或者综合效益最大。

这个问题的难点在哪儿？第一，决策变量混合了二进制变量（某个站建不建）和整数变量（建多少个桩），问题天然是离散的，不能直接用连续优化算法求导；第二，约束条件多且相互耦合，比如服务半径约束、排队等待时间约束（这个是非线性的，需要线性化处理）；第三，实际案例规模一大，候选站几十个、需求点上百个，求解难度迅速上升，这时求解器的选择就非常关键。

需要说明的是，这类项目通常有两种做法：一种是纯学术论文式的建模，大量理想化假设，最后跑个算例证明方法有效；另一种是工程落地式，数据来源、参数估计、约束条件都尽量贴合实际情况。我这次做的是第二种方向，因为单纯为了跑通模型而去跑模型没有太大意义，更重要的是让这套建模和求解思路能迁移到其他相似项目上，比如储能选址、物流节点配置、5G基站规划，本质都是同一类问题。

项目的技术栈选型是matlab + yalmip + cplex/gurobi。matlab负责数据处理、模型表达、结果可视化；yalmip作为建模层，屏蔽了不同求解器的调用差异；cplex/gurobi是底层求解器，负责真正把MIP解出来。这套组合在学术界和工业界都很常见，原因很简单：yalmip让建模变得极其直观，你几乎可以把数学公式直接翻译成代码，而且换求解器只需要改一行设置，不用重写模型。这一点在项目需要对比不同求解器性能，或者license到期需要切换求解器时尤其重要。

2. 数学模型搭建：目标函数、决策变量与约束条件

2.1 决策变量定义

建模的第一步是定义决策变量。这个项目里有两类核心变量：

1. 选址变量：候选站址i是否建站，用二进制变量x_i表示，x_i = 1代表建站，x_i = 0代表不建。

2. 容量变量：站i配置的充电桩数量，用整数变量n_i表示。注意这里n_i是天生的整数，因为充电桩不可能建半个。如果某个站不建，n_i应该为0，这个通过约束x_i = 0时n_i = 0来保证。

此外还有一个分配变量：需求点j的充电需求由哪个站来服务。这个变量可以是0-1变量y_ij（表示需求点j完全由站i服务），也可以是连续变量（表示需求点j的充电需求中有多少比例由站i服务）。至于选哪种，看建模角度：如果假设用户总能找到最近或最合适的站，那么0-1变量更符合现实；如果允许需求按比例分流，那么连续变量会让模型更容易求解，因为减少了整数变量数量。我个人习惯先按0-1变量建模，因为后续加约束更直观，如果求解时间过长再考虑松弛处理。

2.2 目标函数设计

目标函数是整个模型的核心，直接决定了优化方向。常见的目标函数设计有几种：

最小化总成本型：包括建设成本（固定成本+单位容量成本）、运维成本、用户出行成本（时间成本或距离成本）、电网扩容成本。公式上可以写成：最小化∑(固定建设成本_i × x_i + 单位容量成本_i × n_i) + ∑∑(用户出行成本_ij × y_ij × 需求量_j) + 运维成本项。

最大化覆盖和服务水平型：例如最大化充电需求覆盖率，或者最小化用户平均等待时间。

多目标综合型：同时兼顾经济性、服务水平和电网影响，这种通常需要引入权重系数，或者用epsilon约束法转成单目标求解。

我这次用的是综合成本型目标函数。需要提醒的是，不同成本项的量纲可能差异很大，建设成本可能是百万级，运维成本是十万级，用户时间成本折算成费用后可能又是另一个量级。如果直接相加，优化结果会被量级大的项主导。所以归一化和权重设计一定要做，而且要跟项目方确认权重来源，不能自己拍脑袋。比如用户时间成本折算系数，一般可以参考当地人均工资或出行时间价值研究，这些参数合理与否直接影响结果可信度。

2.3 约束条件逐条拆解

约束条件是模型最有讲究的地方，我按类别逐条说：

1. 预算约束：∑(固定建设成本_i × x_i + 单位容量成本_i × n_i) ≤ 总预算。这个约束直接体现了现实中的资金限制，没什么好说的。

2. 需求分配约束：每个需求点至少要有一个充电站服务，即∑y_ij ≥ 1（每个需求点被至少一个站覆盖）。如果允许需求不饱和，可以把右端改成需求覆盖率阈值，比如至少覆盖90%的需求。

3. 容量约束：站i服务的总需求不能超过该站的总容量，即∑(需求量_j × y_ij) ≤ 充电桩数量_n_i × 单桩服务能力。这里单桩服务能力要考虑充电功率、日均服务时长、充电效率折算，是个需要仔细标定的参数。

4. 服务半径约束：需求点j到服务站的i距离不能超过最大服务半径R。这个约束通常写为d_ij × y_ij ≤ R，如果d_ij > R那么y_ij强制为0。实际处理时，可以直接在预处理阶段把距离过大的组合过滤掉，不生成对应的y_ij变量，这样还能减少变量数、加速求解，不用显式写约束。

5. 拓扑逻辑约束：n_i ≤ M × x_i，M是一个足够大的常数。这个约束保证了“没建站就不可能有充电桩数量”。M的取值要足够大，以满足n_i所有合法的上界，但又不能太大，否则会影响MIP求解的数值稳定性。我通常在建模前先估算每个站的最大允许容量，比如受电网可用容量限制，站i最多只能装50个桩，那么M取50就够，不要随便填个10000。

6. 排队等待时间约束（非线性约束线性化的关键）：这一条是很多新手容易卡住的。如果考虑用户到站后可能需要排队，那么等待时间可以近似用M/M/c排队论公式计算。但是排队等待时间的表达式是非线性的、非凸的，没法直接用yalmip表达。常见处理办法是：基于需求量和充电桩数量的比值定义服务强度ρ = 到站率/(服务率 × 桩数)，将等待时间约束转化为对ρ上界的限制。比如要求平均等待时间不超过10分钟，可以通过查M/M/c排队模型数值表，反推出ρ的允许上限，然后把这个上限转化为线性约束。具体来说，如果要求平均等待时间W_q ≤ T，其中W_q是ρ和c的函数，可以先离线计算出对应T的最大允许ρ值ρ_max，然后加入约束：到站率 ≤ ρ_max × 服务率 × n_i。这样就避开了非线性排队公式，把它降为线性约束。

2.4 建模示例：一个抓重点的代码框架

下面给出一个典型的yalmip建模框架，大家可以对照自己的项目改：

matlab复制% 数据定义
I = 30;  % 候选站数量
J = 100; % 需求点数量
dist = rand(I, J) * 20; % 距离矩阵，单位km
demand = rand(J, 1) * 100; % 每个需求点的充电需求，单位kWh/天
fixedCost = rand(I,1) * 100 + 50; % 固定建设成本
unitCost = rand(I,1) * 5 + 2; % 单位容量成本，万元/桩
budget = 3000; % 总预算，万元

% 决策变量
x = binvar(I, 1, 'full'); % 选址变量：0-1
n = intvar(I, 1, 'full'); % 容量变量：整数
y = binvar(I, J, 'full'); % 分配变量：需求点j是否由站i服务

% 目标函数
% 建设成本 + 单位容量成本 + 用户距离成本（折算）
distCost = dist .* repmat(demand', I, 1); % 距离加权需求
objective = sum(fixedCost .* x) + sum(unitCost .* n) + sum(sum(y .* distCost));

% 约束条件
Constraints = [];
% 预算约束
Constraints = [Constraints, sum(fixedCost .* x) + sum(unitCost .* n) <= budget];
% 需求分配约束：每个需求点至少被一个站服务
Constraints = [Constraints, sum(y, 1) >= 1];
% 容量约束：站的服务量不超过容量
CapacityPerPile = 200; % 单桩日服务能力，kWh/天
Constraints = [Constraints, sum(repmat(demand', I, 1) .* y, 2) <= CapacityPerPile * n];
% 拓扑约束：未建站的容量为0
M = 80; % 最大容量上限
Constraints = [Constraints, n <= M * x];
% 服务半径约束：超过最大半径不能分配
R = 8; % 最大服务半径，km
Constraints = [Constraints, y <= (dist <= R)];

% 求解
ops = sdpsettings('solver', 'gurobi', 'verbose', 2, 'showprogress', 1);
sol = optimize(Constraints, objective, ops);

% 结果提取
x_opt = value(x);
n_opt = value(n);
y_opt = value(y);

这里需要重点提示几个容易错的点：

• binvar和intvar的第三个参数'full'，在旧版yalmip里可能不是必需的，但在有矩阵分解场景的模型中建议显式声明，避免隐式创建对称变量矩阵导致变量数翻倍。
• y <= (dist <= R)这种写法在yalmip里是合法的，它直接把逻辑判断的结果作为约束上界。但要注意，如果dist刚好等于R，是包含在服务范围内的。
• 目标函数里sum(sum(y .* distCost))是在计算所有分配路径上的总距离成本。这里distCost已经乘了demand，所以它表示的是“距离×需求量”的总和，需要用这个值乘以单位距离成本折算系数才是最终费用。

3. 求解器选型与环境配置指南

3.1 cplex和gurobi怎么选

做MIP的求解器无非那么几个：cplex、gurobi、以及免费开源的cbc、scip。对于那些数据量不上不下、又对求解时间有要求的项目，cplex和gurobi是事实标准。两者的核心算法几乎一样：branch and cut + 各种启发式 + 预求解。实际使用中，gurobi的许可证对学术用户友好（免费），社区活跃度高，并且近几年的版本在MIP求解速度上经常持平或略胜cplex；cplex则在老牌工业界里积累了庞大的存量用户。就这个充电站优化项目而言，两者都能轻松解决中小规模算例。如果候选站几十个、需求点几百个，变量数几千到几万个，cplex和gurobi通常几分钟内能给出高质量解；如果问题再扩大十倍，这时候gurobi的并发和参数调优能力体现出优势。

我的建议是：不要纠结于“哪个更强”，而要把重点放在“你的模型是否建得好、约束是否紧凑、初始解是否给得合理”。一个建模松散的模型，换再好的求解器也救不回来。反过来，模型紧凑、有好的初始解，cbc这样的免费求解器都能在可接受时间内解出来。所以第一步是建模和预求解做扎实，第二步才是选求解器。

3.2 matlab + yalmip + 求解器安装联动

这个组合的安装链路上有几个常见的坑，我一个个说：

yalmip安装：yalmip是一个纯matlab工具箱，下载后只需要把文件夹路径加到matlab搜索路径里即可。具体做法：主页 → 设置路径 → 添加并包含子文件夹。然后验证是否安装成功，在命令行输入yalmiptest，会列出检测到的求解器。这里的关键是：yalmiptest只会检测当前matlab搜索路径下能找到的求解器，如果cplex或gurobi安装好了但matlab找不到，它会显示not detected。

gurobi安装与matlab联动：gurobi安装好后，需要把matlab接口的路径添加到matlab搜索路径。具体位置一般在gurobi安装目录下的matlab子目录，例如/opt/gurobi952/linux64/matlab。添加后，运行gurobi_setup（部分版本运行gurobi）来验证接口是否可用。有个高频问题：gurobi是用特定版本GCC编译的，和matlab自带的运行时可能存在兼容性问题。如果运行gurobi_setup时提示GLIBCXX版本不对，通常是系统GCC版本和matlab内置版本冲突。解决办法是设置环境变量LD_PRELOAD指向gurobi自带的libstdc++，或者用matlab的setenv函数指定动态库路径：

matlab复制setenv('LD_PRELOAD', '/opt/gurobi952/linux64/bin/libgurobi95.so');

具体路径以实际安装为准。

cplex安装：cplex的matlab接口在安装目录下的cplex/matlab文件夹。同样需要添加到matlab搜索路径。此外，cplex在个别版本上需要配置Java环境，如果调用时报Java相关错误，需要检查matlab的Java路径是否指向了正确的JDK版本。这类问题最麻烦，因为matlab默认自带JRE，如果系统装了其他版本Java可能导致冲突。

3.3 yalmip调用求解器的底层细节

yalmip传递模型给求解器时，做了几件重要的事：把yalmip的变量对象转换成cplex/gurobi需要的矩阵形式；检测模型类型（LP、QP、MIP、MIQP）；根据需要自动对约束做预处理。因此，同一个模型在不同求解器上的表现会略有差异，根源就在yalmip对模型做的变换方式不同。但大多数情况下，这些问题并不需要用户深究，只要知道一点：在yalmip里切换求解器就是一行代码：

matlab复制ops = sdpsettings('solver', 'cplex');  % 或者 'gurobi'

切换后建议做一次结果验证：用同一个算例分别用cplex和gurobi求解，对比目标函数值和最优解一致性。如果两个求解器给出的最优目标值有微小差异（比如10^-6量级），这是求解器容差不同导致的，不用奇怪；如果有明显差异，那就要回头检查模型是否有数值稳定性问题。

3.4 求解器参数调优速查

下面给出几个对这个项目比较有用的参数配置：

需要说明的是，这些参数在yalmip里通过sdpsettings设置时，格式略有区别。gurobi参数可以直接通过sdpsettings('gurobi.TimeLimit', 600)方式传递，cplex类似。如果你直接在sdpsettings里写'TimeLimit', 600，yalmip只会把它识别为通用求解器选项，不一定能传到cplex/gurobi。这一点经常被忽略。

4. 实操过程：从数据到结果的完整复盘

4.1 数据准备与预处理

建模之前，数据质量决定了模型地板高度。这个项目至少需要准备四类数据：候选站址信息（经纬度、地块面积、电网容量、建设成本）、需求点信息（位置、充电需求量、时段分布）、路网距离矩阵（不是直线距离，而是实际的出行距离）、以及经济参数（折算系数、预算上限）。

距离矩阵的处理在这次项目里是个重点，我最初为了省事直接用经纬度算球面距离，后来发现和实际情况偏差太大。比如两个点直线距离3公里，由于快速路走向问题，实际驾车距离可能要8公里。充电站服务半径约束如果用了低估的距离矩阵，会出现模型认为用户在服务范围内、实际却够不着的情况。后来改用高德/百度的路径规划API批量获取OD距离矩阵，虽然调用量大、费时间，但结果可靠多了。这里给个小建议：数据量在几百个点以内时，可以用地图API批量算；上千个点以上建议用OSM路网数据做路径计算，或者用空间插值方法近似，否则API调用成本太高。

预处理阶段还有一个容易被忽视的步骤：删掉明显不合理的候选组合。比如需求点j到候选站i的距离已经超过最大服务半径，那么在生成变量y_ij时直接不生成，而不是生成后加约束限制。这能显著减少变量数量，尤其在大规模场景下，效果非常明显。

4.2 从小规模算例开始验证

任何认真做优化项目的人都不会一上来就跑大规模数据。我的做法是先用一个小规模算例验证模型逻辑是否正确：候选站5个，需求点10个，约束和求解器全部按正式配置来。这个阶段的目标不是看优化结果好不好，而是确认模型没有逻辑错误——约束有没有写反、目标函数的系数有没有放错位置、求解器能否正常收敛。

小规模算例还有一个作用：手动验证最优解。规模小到一定程度，你可以用穷举法或手工推算验证优化结果是不是合理的。比如5个候选站、最多2^5种选址组合，人工检查每种组合对应的最低成本，和求解器输出的结果对比。这个步骤能极大增强对模型的信心。很多人跳过这步，直接在大型数据上跑，出问题后只能干瞪眼排查误差来源，反而更费时间。

4.3 全量数据求解与结果分析

小规模验证通过后，进入全量数据求解阶段。我这次的规模是：候选站30个，需求点120个，二进制变量x_i 30个、整数变量n_i 30个、分配变量y_ij 3600个。模型规模不算大，gurobi默认参数下跑了大约80秒达到最优解，最优目标值比初始可行解降低了约18%。如果设置1%的MIPGap，求解时间可以压到30秒以内，这在工程交互场景下是可接受的。

结果分析阶段我习惯从三个维度看：

1. 选址结果的空间分布：把选中的站点和需求点画在地图上，看是否存在明显不合理的分布。比如两个站距离过近、服务区重叠严重，这可能意味着模型倾向于扎堆建设，需要检查是不是容量约束太松或者距离成本权重太大。

2. 容量利用率分析：计算每个站的实际服务量与容量比值，找出过载站和低利用站。这个信息可以为后续运营调整提供依据。如果某个站的容量利用率不到50%，说明资源浪费了，可以考虑减少桩数或调整选址。

3. 敏感性分析：改变关键参数（预算、单位距离成本权重、最大服务半径），观察结果变化趋势。比如预算从2000万提高到4000万，最优解里站的数量和总容量如何变化；服务半径从8km缩到5km后，需要新增多少站点才能满足覆盖率。这些敏感性结论是项目报告中非常有价值的输出。

4.4 求解结果可视化方案

matlab做结果可视化是强项，几个必备的图：

matlab复制% 站点-需求点分配关系图
figure;
plot(demand_x, demand_y, 'bo', 'MarkerSize', 5, 'DisplayName', '需求点');
hold on;
plot(station_x(x_opt==1), station_y(x_opt==1), 'r^', 'MarkerSize', 12, 'DisplayName', '选中站点');
% 画分配连线
for i = find(x_opt==1)'
    served = find(y_opt(i,:) > 0.5);
    if ~isempty(served)
        plot([station_x(i), demand_x(served)], [station_y(i), demand_y(served)], '-', 'Color', [0.7 0.7 0.7]);
    end
end
legend('Location', 'best');
xlabel('经度'); ylabel('纬度');
title('充电站选址-需求分配结果');

另一个值得画的是容量热力图或柱状图，展示每个选中站点配置的充电桩数量，以及对应的服务需求量。这类图形对于向项目汇报、给非技术决策者看结果，非常有说服力。毕竟模型算出来的东西是一串数字，只有可视化后才能直观判断它是合理还是反直觉。

5. 常见问题与排查技巧实录

5.1 求解器报“infeasible problem”怎么办

模型不可行是MIP项目里最经常遇到、也最让人头疼的问题。所谓不可行，就是约束条件过于苛刻，找不到任何满足所有约束的解。排查思路：

第一步：是否约束矛盾。检查是否存在明显冲突的约束，比如预算上限过小，而固定建设成本又强制了某个必选项，导致无论如何都超预算。

第二步：用yalmip的diagnostic工具定位。在优化完成后，检查sol.problem值。如果为1（infeasible），可以用松弛惩罚法逐步放宽约束，定位最紧的约束是哪一个。具体做法：给每个约束加一个松弛变量，把原问题改成“惩罚最小化不可行量”的问题，求解后观察哪些松弛变量不为0，这些就是导致不可行的元凶。在yalmip里实现：

matlab复制s = sdpvar(length(Constraints), 1);
Constraints_slack = [Constraints - s <= 0, s >= 0];
optimize(Constraints_slack, sum(s));

这个方法虽然听起来土，但确实是最有效的。

第三步：检查数据是否异常。比如某个需求点的需求量填成了0，或者某个距离矩阵元素缺失被填充成了0，可能导致容量约束被瞬间满足然后误导优化方向。这类数据异常在排查时要格外留意。

5.2 求解时间过长，如何加速

当MIP规模变大，求解时间可能从几十秒飙到几小时。常见加速手段按优先级排列：

1. 模型层面的紧凑化：重新审视约束表达，用更紧的约束力度减少branch and cut的搜索空间。一个典型例子是Big-M约束中M的取值要尽量紧。上面提到的容量上限M如果从100降到50，求解速度可能提升一个档次，因为求解器在预求解阶段可以排除更多不可能的分支。

2. 增加初始解（warm start）：用启发式方法（例如贪婪算法：优先选择单位成本低、覆盖需求多的候选站）生成一个可行解，然后通过yalmip的assign和optimize的'usex0'选项传给求解器。一个好的初始解对MIP求解器帮助极大，尤其是你允许的MIPGap较小时，求解器可以在搜索初期就锁定一个高质量下界。

3. 调整求解器参数：如前面提到的MIPGap=0.01、TimeLimit=600，以及gurobi的MIPFocus参数（设为1表示优先找可行解，设为2表示优先改进下界，设为3表示平衡）。根据实际需求选择侧重点。

4. 问题分解：如果模型规模实在太大，比如候选站几百个、需求点上万个，单机内存都不够，就考虑用Benders分解或者Lagrange松弛。但这两个方法实现复杂度高，工程中通常先用前三种手段，实在不行再上分解算法。这是最后的手段，不是第一选择。

5.3 数值稳定性问题：结果出现NaN或异常解

这个问题比较隐蔽。MIP求解过程中如果出现数值病态，可能出现NaN、错误剪枝、甚至返回不可行解。常见诱发因素：

• 目标函数系数和约束系数尺度差异过大（比如成本是10^6量级，需求量是10^-2量级）。解决方法是重新归一化数据，比如成本单位为百万元，而不是元；需求量单位为百kWh，而不是kWh。
• Big-M值选取过大。M过大导致约束矩阵条件数恶化，求解器精度下降。尽量用紧M。
• 变量上下界设置不合理。比如n_i的上界设为10000，而实际只需要50，这会导致搜索空间巨大且数值问题频发。

排查方法：开启求解器的数值报告（gurobi的NumericFocus=3，cplex类似的numericalEmphasis），查看求解日志中是否有数值困难相关警告。如果日志中频繁出现"Numerical trouble"或"Condition number"相关提示，就需要回头检查数据尺度问题了。

5.4 换求解器后结果不一致

项目中途可能会因为license问题从gurobi切到cplex，或者反方向切换。这时可能发现两个求解器给出的最优解、最优值不一致。先不要慌，绝大多数情况下不是模型错了，而是两种可能性：

1. MIPGap容差不同：两个求解器默认的MIPGap不同。gurobi默认是1e-4，cplex默认是0（以最终证明最优性为准），所以两者在固定时间内给出的解可能不同。解决办法：让两个求解器使用相同的MIPGap和TimeLimit再对比。

2. 多解问题：同一个目标函数值对应多个最优解，两个求解器可能找到不同的最优解（但目标值相同或近似）。这是正常的。如果目标值差异很大（超过容差），再考虑是否存在数值问题。

有一个小技巧可以快速验证一致性：把求解器的最优解固定为变量初值，重新用另一个求解器求解。如果目标函数值比第一次的结果更好，说明确实存在问题。

5.5 参数敏感性分析实操

敏感性分析不只是在项目汇报里加分，更重要的是它能告诉你模型的稳定区域在哪里。我的实操做法是：固定其他参数，逐一扫描目标参数，观察最优解的变化，并把结果画成折线图或热力图。核心参数一般选这几个：

• 总预算：从80%到120%基准值扫描，观察建站数量和目标函数值变化，判断预算约束是否起关键作用。
• 最大服务半径：从6km到12km扫描，观察覆盖率变化。
• 单桩日服务能力：这个参数受技术进步影响，未来快充普及后可能翻倍。观察它对总容量配置的影响，能判断模型是否过度依赖单个参数。
• 用户时间价值折算系数：这个参数比较虚，不同来源可能差异很大。敏感性分析如果显示它对结果影响显著，那么就需要花更多精力去校准这个参数。

6. 经验总结与项目扩展思路

我在这个项目里最大的体会是：优化建模中80%的时间不是在写模型，而是在处理数据和理解问题的业务逻辑。模型本身是数学公式的翻译，翻译清楚了，求解器就是一把自动步枪，指哪打哪；但如果你不理解业务场景里的等价关系、不知道哪些约束是主要矛盾、哪些是可以合理简化的次要因素，建出来的模型就有两个极端：要么过于简化、脱离实际；要么过于精细、无法求解。

关于模型复杂度控制，我后期摸索出一个可靠度较高的做法：先做一个只包含核心约束和最小目标项的“骨架模型”，跑通之后，再逐条向里面添加约束和细化目标。每加一条，都先在小规模算例上验证一次，确认没有引入错误或不可行，再让它参与全量求解。这个迭代过程虽然慢，但是可以确保模型每一步都是可解释、可验证的。千万不要一次性把所有细节全部堆进模型里，真出了问题，排查成本会指数级上升。

从扩展角度说，这个项目的模型框架完全可以迁移到其他类似的设施选址问题上：共享单车停放点布局、换电站选址、快递末端网点设置、分布式储能配置，本质上都是“在离散候选点中选择有限个设施，并确定其服务能力，在预算和容量约束下最大化服务效益或最小化成本”的结构。只要换一套参数、换一个目标函数细节，模型骨架可以直接复用。如果你后续要考虑多时间尺度的动态规划（比如充电站分阶段建设、需求逐年增长），只需在现有模型上增加时间维度变量，把静态MIP扩展为多阶段MIP，yalmip仍然可以胜任，只是求解难度会进一步加大。

最后再分享一个小技巧：项目交付时，一定要把求解器的随机种子固定下来，否则同一份代码每次运行结果可能不同（尤其是并行求解时）。在yalmip里设置方式很简单：

matlab复制ops = sdpsettings('solver', 'gurobi', 'gurobi.Seed', 12345);

固定种子后，结果可复现，这在调试、复盘、写报告时无比重要。我早期不重视这一点，有一次给客户演示时换了台电脑跑，结果最优解结构变了，解释了半天才说明白原因。从那以后，所有项目我都会固定随机种子和求解器参数，避免任何不必要的麻烦。