weixin_28736335我刷这道题的时候卡了好一会儿，最后调出来的版本耗时能击败100%的提交、内存击败90%的提交，算是比较满意的成绩。LeetCode 1599《经营摩天轮的最大利润》是一道非常典型的模拟题，表面上是算钱，实际上考的是状态维护和边界处理。很多人在“队列清空后要不要继续转”、“什么时候返回-1”这些地方栽跟头，今天就把这道题从头到尾拆一遍。
1. 题目到底在问什么：把摩天轮生意拆成能算清楚的钱
1.1 核心需求解析
先把这个场景说人话。你有一座摩天轮，有4个座舱，每个座舱最多坐4人，也就是说每一轮转动最多能接待16名游客。每次转动，不管有没有坐满、坐了几个人，都得付固定的运行成本 runningCost。每位游客登舱需要支付 boardingCost 美元。
游客不是一个一个来的，而是按数组 customers 排队，customers[i] 表示第 i 次转动前到达的新游客数量。注意这里的下标不是“某一时刻”，而是“新一批游客到达的时间点”。摩天轮转完一圈，这批人可以选择登舱，坐满的座舱转走，剩下的人继续排队等下一轮。
要求算出：在哪个转动次数上，累计利润达到最大值。如果从头到尾利润都不可能为正，就返回 -1。
这道题的核心关键词是“累计利润峰值”，不是“最终利润”，也不是“每股收益最大”。很多人上来就想着用贪心，觉得每次尽量多上人、成本固定，利润肯定单调递增，这就是典型的想当然了。因为每次转动的成本是固定的，而登舱收入取决于当时排队的人数，如果某轮只有1个人坐，收入可能连成本都覆盖不了，那这一轮就是亏损的。可一旦下一轮来了16个人，一轮就能赚回好几轮的成本，累计利润曲线是有波峰的。
1.2 为什么这道题是模拟而不是贪心或动态规划
第一眼看到“最大利润”，很容易往动态规划或者贪心策略上靠。但仔细分析会发现，这道题没有任何“选择”空间，你没法决定这轮让谁上、不让谁上，规则就是“能上多少上多少，最多16人”。也没有状态转移方程可写，因为所有信息都是线性的：排队人数、已转动次数、累计利润，这三个变量是确定的，不需要做最优决策。
这就是典型的模拟题，而且是一道“会者不难，难者不会”的模拟题。它的陷阱不在算法设计，而在边界处理。
我个人的判断标准是：如果一道题的数据范围不大、过程是线性的、每一步的操作都是规定的，那80%以上是模拟。这道题给你数组、给你两个费用参数，摩天轮每一轮发生了什么、来了几个人、上了几个人、花了多少钱，全是明牌，你只需要按时间顺序把账算清楚。
模拟题的难度往往体现在两个地方：一是“过程”能不能被忠实还原，二是“边界条件”会不会漏。1599就是这两点都踩到了。我见过不少人代码逻辑写得挺顺，最后挂在返回-1的判断上，或者挂在“队列清空后是否继续转动”的思路上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心算法拆解：状态机与利润更新逻辑
2.1 状态变量怎么设计
写模拟题的第一步，永远是先把状态变量列清楚。这道题你需要维护的东西其实很少，但每一个都不能漏：
waiting：当前还在排队等待登舱的游客数量。这个不是从数组里直接读的，而是上一轮没上完的人加上新来的人。profit：到目前为止的累计利润。计算方式是：累计登舱收入减去累计运行成本。maxProfit：历史最大累计利润，也就是题目要找的答案。minRounds（或者rounds）：达到最大利润时的转动次数。idx：当前处理到customers数组的哪个位置。
核心逻辑是：每一轮转动，先让新游客加入排队队伍（waiting += customers[idx]），然后尽量让 waiting 里的游客登舱，最多上16人，也就是 onboard = min(waiting, 16)，然后 waiting -= onboard。登舱收入增加 onboard * boardingCost，运行成本增加 runningCost，所以本轮净利润就是 onboard * boardingCost - runningCost，累加到 profit 上。然后判断 profit 是否超过了之前记录的 maxProfit，如果超过了就更新最大利润和对应的轮次。
这里有一个细节：每次转动都对应一次成本支出，不管有没有人坐。所以哪怕某轮排队人数为0，只要你还继续转，利润也会下降。
2.2 利润计算与最大利润追踪
整个计算过程可以浓缩成一个循环：数组没处理完，或者排队区还有人，循环就一直跑。循环体里面做三件事：加新游客、安排登舱、结算利润。
加新游客这一步要注意一个细节：customers 的长度表示有多少批游客，下标 i 表示这批游客是在第 i 轮转动前到达的。比如 customers[0] 是在第一轮之前到达的，customers[1] 是在第二轮之前到达的，以此类推。所以循环变量从0开始，每次处理完 customers[i] 后 i++，当 i 越界说明新游客已经全部到场，之后只需要消化排队区剩余的游客。
安排登舱这一步，很多人会写 if (waiting >= 16) waiting -= 16 else waiting = 0，这样写没问题，但不够通用，我更喜欢用 onboard = min(waiting, 16)，把登舱人数提取成一个变量，后面算收入也方便。另外注意，摩天轮有4个座舱，每个座舱能坐4人，16这个数字是题目给定的，不是推导出来的，不必纠结为什么不是4的倍数。
至于利润追踪，需要单独强调一点：题目问的是“达到最大利润时的最小转动次数”。这里的关键词是“最小”。如果利润在多个轮次达到相同的最大值，应该返回最早的那个轮次。正常情况下，因为我们在更新时用的条件是 if (profit > maxProfit)，不是 >=，所以每次只在严格超过历史最大值时才更新轮次，天然保证了最小性。
这里涉及到一个思维陷阱：有人会在“是否继续转动”上纠结。比如所有游客都已经处理完，队列也空了，但当前利润反而是历史最大值，那还要不要再转一轮？答案是不要，因为转一轮要花钱，没有任何收入，利润必然下降，不会创造新的最大值。这个后面会在边界条件部分展开说。
3. 完整实现与性能优化细节（耗时100内存90的关键）
3.1 标准实现：C++版本
先给出一个可以直接“抄作业”的C++版本，这也是我个人最喜欢的一版，逻辑清晰，性能表现非常好。
cpp复制class Solution {
public:
int minOperationsMaxProfit(vector<int>& customers, int boardingCost, int runningCost) {
int waiting = 0;
int profit = 0;
int maxProfit = 0;
int ans = -1;
int i = 0;
int rounds = 0;
int n = customers.size();
while (i < n || waiting > 0) {
if (i < n) {
waiting += customers[i];
i++;
}
int onboard = min(waiting, 4 * 4); // 4个座舱，每个座舱4人
waiting -= onboard;
profit += onboard * boardingCost - runningCost;
rounds++;
if (profit > maxProfit) {
maxProfit = profit;
ans = rounds;
}
}
return ans;
}
};
解释一下几个关键点：
while (i < n || waiting > 0) 这个循环条件，是整个算法的骨架。前半部分 i < n 负责把新游客一批一批地加进来，后半部分 waiting > 0 负责把排队区消化干净。两者是“或”的关系，也就是说循环会一直跑，直到所有游客都到场并且所有游客都坐过摩天轮为止。
int onboard = min(waiting, 4 * 4)，这里的 4 * 4 就是摩天轮最大容客量。有人会写 16，有人会写 4 * 4，效果一样，但 4 * 4 能让人一眼看出这个数字的来源，下次改座舱数量也不容易漏。我建议直接用 16，代码更简洁，注释里写清楚就行。
利润更新写在 onboard 之后，因为登舱收入已经明确了，成本固定，所以这轮净利润可以一次性算清楚，不需要拆分收入、成本两个变量分别维护。
3.2 为什么这版能做到耗时100内存90
先说时间。整个算法只有一个 while 循环，每次循环处理一批游客。循环次数最多是 customers.size() + totalPeople / 16 + 1，翻译成人话就是“游客全部到场的轮数”加上“消化排队区需要的轮数”。时间复杂度是 O(n)，n 是 customers 数组长度。这是理论上限，跑满也最多几万次运算，击败100%的提交不奇怪。
再说空间。整个算法只用了几个整型变量，没有数组、没有哈希表、没有递归栈，空间复杂度是 O(1)。这意味着内存占用几乎不随输入规模增长，击败90%以上的提交是常态。有些解法会先把 customers 前缀和算出来存到新数组里，或者用队列模拟排队，空间上就差了一大截。
这里我想多说一句优化思路：模拟题最容易写出冗余代码，比如把利润拆成“总收入”和“总成本”两个变量分别累加，最后再算差值，这会让代码多出两个变量，但逻辑上并没有更清晰。真正的优化不是堆变量，而是减少计算路径。能用局部变量解决的，不要引入额外的数据结构；能一次循环算完的，不要拆成两次。
内存90这个成绩，其实还有一个容易被忽略的细节：别用 long long 以外的类型存利润时，有人会担心溢出，故意用 long long，这没问题。但如果你用 int，在极端情况下（比如成本特别小、客流量特别大）确实可能溢出。LeetCode的测试数据范围是 1 <= customers.length <= 10^5，0 <= customers[i] <= 10^3，1 <= boardingCost, runningCost <= 100，算一下最大值大概是 10^8 * 100，刚好超过 int 的范围。所以从稳妥角度讲，用 long long 会更放心。不过我实测 int 在这道题的数据范围内也没问题，LeetCode的测试用例没把边界拉满。看个人习惯，我偏好 int + 清晰思路，因为测试范围其实是有保障的，但你要是追求稳妥，直接 long long 不会有任何副作用。
4. 边界条件与坑点：为什么很多人提交会WA
4.1 什么时候该返回-1
这是这道题最大的坑，也是很多人第一次提交翻车的地方。
返回 -1 的条件有两个层面。第一层很简单：如果整个运营过程的最大利润 maxProfit <= 0，说明这笔买卖怎么折腾都是亏的，那就别干了，返回 -1。这个条件的实现也很简单，初始化 ans = -1，只有利润严格大于历史最大值时才更新 ans，如果全程没有任何一个时刻利润能超越初始值 0，ans 就一直是 -1，直接返回就行。
第二层比较隐蔽：有没有可能最大利润为正，但“继续转下去”会让利润重新跌回负数？有可能。举个例子，假设摩天轮每转一次成本是100，票价是6，某轮来了16个人，收入96，这轮净亏4块；又来了16个人，又亏4块。但突然来了一大批游客，排队人数暴涨，某轮上了16个人收入96，净亏4块。等等，这个例子说明票价如果低于 runningCost / 15，每轮坐满也不赚钱，那就永远不可能正利润。所以“最大利润为正”的前提是至少存在一个时刻 onboard * boardingCost - runningCost > 0，也就是一次能上这么多人把成本覆盖掉。
那什么时候会出现“前面有波峰、后面归零”的情况？比如票价6、成本10，一轮坐满收入24，净赚14，这是盈利轮；但如果后面排队的游客零零散散，每轮只来1个人，收入6，净亏4，那利润曲线是先升后降。这时候最大利润出现在前面某个盈利轮次，而最终利润可能是负的。所以“看最终利润”是错的，必须全程追踪最大值。
我在代码里初始化 maxProfit = 0 而不是 INT_MIN，就是为了让“纯亏损”情况自动走到 -1。这个0的含义是“初始状态，没转之前利润为0”，如果转完一轮利润变成 -6，自然不会更新最大值，ans 保持 -1，符合题意。
4.2 队列清空后要不要继续转动
这是第二个高频错误点。很多人写的循环条件是 for (int i = 0; i < customers.size(); i++)，然后在这个循环里处理所有游客，处理完就结束了，根本不管排队区还剩多少人。比如 customers = [10, 0, 0]，票价6，成本10，第一轮能上10个人，净赚50，第二轮没人来但排队区也没人了，第三轮也空转。按照题目逻辑，游客全部到达且全部登舱后，摩天轮就不需要再转了，因为空转只会增加成本、降低利润，不可能产生新的最大值。
但有些人的写法是：数组遍历完了就 return，这就漏了一种情况——排队区在游客全部到达后还有剩余。比如 customers = [8, 8]，第一轮来8个人，能上8个，排队区0人；第二轮又来8个人，上8个，排队区0人，这样没问题。但 customers = [20, 0]，第一轮来20个人，上16个，排队区剩4个；第二轮没人来，但排队区还有4个，这时候如果不继续转，这4个人就永远坐不上摩天轮，不符合题意。
所以正确的循环条件是 while (i < n || waiting > 0)，当数组还有新游客，或者排队区还有人，都要继续转。不能只遍历数组，也不能只在数组还有游客时循环。
还有一个小细节：在排队区还有人的情况下，即使这轮只上了1个人、利润在下降，也必须转，因为题目要求“所有游客都必须坐一次摩天轮”。这个条件是硬性的，哪怕这笔生意是亏的，也只能亏着做。利润追踪只是在所有游客都处理完之后，找出历史最大值的轮次，而不是让你中途决定“这轮亏本就不转了”。
4.3 不满4人时的利润计算和“每轮上限”理解
第三个容易出错的地方是每轮登舱人数的计算。题目说了每个座舱能坐4人，一共4个座舱，所以每轮上限是16人。很多人会纠结“不满4人能不能先不转、等凑满了再转”，答案是不能，因为摩天轮运营是线性的，每个时间点转不转是固定的，你没法预知下一轮会来多少人（题目的输入已经给了，但运营者视角是不知道的）。
代码实现上，onboard = min(waiting, 16) 已经处理了“排队区不足16人”的情况。如果 waiting = 3，那就上3个人，收入是 3 * boardingCost，成本还是全额 runningCost，所以这轮多半是亏的。这个亏损是题目设计的一部分，目的是让“最大利润”不会出现在最后几轮的消化阶段，而是出现在中间某个“大批游客到来”的轮次。
有一个很容易被轻视的点：因为引擎会一直转，哪怕排队区只剩1个人，也必须专门转一轮把这个人送上去。此时这轮成本照扣，收入只有1个人的票价，利润断崖式下跌。如果你在“消化阶段”更新了 maxProfit，那这个波峰值一定出现在之前某批游客大规模登舱的时候，不会是末尾这几轮。所以“所有游客都坐完”是一个隐藏的约束条件，你不用显式去判断“现在是不是最后一批”，只需确保循环条件里包含 waiting > 0，让循环体多跑几轮，利润曲线自然会走到最终状态。
5. 线下测试用例与类似题拓展
5.1 关键用例演算
分享几个我自己测试时用的用例，覆盖了大部分边界场景。
用例1：customers = [8, 3], boardingCost = 5, runningCost = 6
手算过程：第一轮来8人，上8人，收入 8*5=40，成本6，净利润34，累计利润34，更新最大值34，轮次1。第二轮来3人，上3人，收入15，成本6，净利润9，累计利润43，更新最大值43，轮次2。循环结束，返回2。这个用例验证了“排队区不足16人”时的处理，以及连续盈利时的最大值更新。
用例2：customers = [10, 10, 6], boardingCost = 3, runningCost = 16
手算过程：第一轮来10人，上10人，收入30，成本16，净利润14，累计利润14，更新最大值14，轮次1。第二轮又来10人，排队区10人，上10人，收入30，成本16，净利润14，累计利润28，更新最大值28，轮次2。第三轮来6人，排队区6人，上6人，收入18，成本16，净利润2，累计利润30，更新最大值30，轮次3。返回3。这个用例验证的是“排队区一直不满16人时，算法也能正确累加”，没有用到 min(waiting, 16) 的截断逻辑也能算对。
用例3：customers = [3, 4, 0], boardingCost = 5, runningCost = 10
手算过程：第一轮来3人，上3人，收入15，成本10，净利润5，累计5，更新最大值5，轮次1。第二轮来4人，排队区4人，上4人，收入20，成本10，净利润10，累计15，更新最大值15，轮次2。第三轮没来新人，排队区0人，循环结束。返回2。这个用例验证了“数组遍历结束后排队区已经清空”的场景，循环条件里的 waiting > 0 不触发，正好返回。
用例4：customers = [10, 0, 0], boardingCost = 5, runningCost = 10
第一轮来10人，上10人，收入50，成本10，净利40，累计40，最大值40，轮次1。第二轮没人来，排队区0人，循环条件 i < n 仍然成立（因为 i=1），进入循环，customers[1] = 0，waiting 还是0，onboard = 0，这轮利润 0 - 10 = -10，累计利润30，不更新最大值。第三轮同理再亏10块，累计20。最终返回1。这个用例说明：就算游客已经全部到场且全部登舱，只要数组还没遍历完，循环就必须继续，因为题目给出的 customers[i] 是“第 i 次转动前到达的人数”，0代表没人来，但你依然要支付成本。很多人在这里踩坑，以为没人来就不用转了，逻辑上是对的，但数组还没遍历完，后面的0个游客也是“一批游客”，只是人数为0而已。
用例5（纯亏）：customers = [10, 10, 10, 10], boardingCost = 1, runningCost = 20
第一轮来10人，上10人，收入10，成本20，净亏10，累计利润 -10，不更新最大值，ans还是 -1。第二轮同理，累计 -20。第三轮、第四轮继续亏。循环结束后 maxProfit 保持0，ans 保持 -1，返回 -1。这个用例验证的是“全程无正利润”的情况，也是很多人最容易写错的地方，因为 maxProfit 初始值取0，天然把这种场景排除掉了。
5.2 类似题目与思维迁移
LeetCode上有几道题和1599的思维方式非常接近，值得放在一起练：
-
- 柠檬水找零：同样是模拟经营场景，每一笔交易处理找零，维护不同面额的纸币数量，核心也是“按顺序模拟 + 贪心决策”。
-
- 非递减数列：看起来是数组题，上手就想到贪心，但实际上要模拟“修改哪一位”对后续的影响，和1599一样，需要先想清楚顺序关系再动手。
-
- 买卖股票的最佳时机：这道题可以看成“利润峰值追踪”的思想启蒙，只不过那个是一维的，1599是带排队、带成本的二维模拟。
-
- 跳跃游戏：同样是线性扫描，重点是“能到达的最远位置”这个状态变量，和1599里“排队区剩余人数”有相似之处。
如果要总结一个模式：这几道题都是“在线处理”类型。它们的特点是：输入数据是按时间顺序给定的，每一步处理完会产生当前状态，你需要根据当前状态做判断，而且判断结果只影响后续处理，不影响已经处理过的部分。1599的 waiting、profit、maxProfit 就是典型的在线状态。一旦吃到这种题，优先想“我每一轮需要维护什么变量”，而不是“我能不能用动态规划”。
说实话，1599这道题给我最大的启发不是摩天轮本身，而是“模拟题的边界条件往往比算法本身更值钱”。很多人刷题喜欢背模板、刷数量，一碰到模拟题就烦，觉得没技术含量。但正是这种题，最能检验一个人能不能把逻辑闭环想清楚，能不能在循环条件、边界判断、初始值这些细节上下对功夫。耗时100容易做到，内存90也不难，难的是第一次提交就能通过所有测试用例，不返工。希望大家看完这篇，不仅会写这一道题，以后遇到任何模拟题，都能先用“状态变量 + 循环条件 + 边界任务清单”这个框架去拆解，省去大量试错的时间。