假设你正在维护一个电商库存服务，多个并发请求可能同时尝试把库存字段从 10 更新为 20，或者反向从 20 更新为 10。如果直接使用 $set 做覆盖，最后写入的请求会无条件覆盖之前的值，导致库存数量忽高忽低。MongoDB 提供了两个专用于边界值更新的操作符：$min 和 $max。它们的工作方式不是无条件赋值，而是先与当前字段值做比较，只有满足相对大小关系时才写入新值。这种机制特别适合维护历史最低价、最高分、传感器最小温度等需要单向约束的数值场景。
$min 的语义是取较小值：如果新提供的值小于当前字段值，则更新；如果当前字段不存在，则直接设置为新值；如果新值大于或等于当前值，则不做任何修改。$max 的语义相反：只有新值大于当前值或字段不存在时才写入。这里的比较是同一个更新操作内部完成的，不需要应用层先读取再判断，因此天然具备原子性。对于单个文档来说，更新过程中 MongoDB 会持有文档级并发控制，比较与写入不会被其他更新打断。
一、$min 与 $max 的命令结构和基本行为
在 MongoDB Shell 中，$min 和 $max 都作为更新操作符出现在更新文档中。下面是一个使用 $min 的示例：
db.products.updateOne(
{ _id: 1001 },
{ $min: { stock: 15 } }
);
这段代码会查找 _id 为 1001 的文档，然后对 stock 字段执行边界写入。如果当前 stock 是 10，新值 15 不小于 10，因此文档保持不变；如果当前 stock 是 20，新值 15 小于 20，字段会被更新为 15；如果 stock 字段不存在，MongoDB 会创建该字段并直接写入 15。这里要特别注意，$min 的比较基准是字段当前值，而不是集合中所有文档的最小值。
再看 $max 的示例：
db.scores.updateOne(
{ _id: 2001 },
{ $max: { highScore: 88 } }
);
如果 highScore 当前是 75，新值 88 更大，字段更新为 88；如果当前是 90，新值 88 更小，不会发生任何修改；如果字段不存在，则设置为 88。可以看出，$min 和 $max 的核心价值在于它们提供了一种条件更新，而不是无条件覆盖。这个条件判断在数据库端完成，避免了应用层先查询再更新的竞态窗口。
同一个更新文档中可以对不同字段分别使用 $min 和 $max，例如同时更新日最低温和日最高温：
db.weather.updateOne(
{ station: "A01", date: "2024-05-20" },
{
$min: { minTemp: 12.5 },
$max: { maxTemp: 31.2 }
}
);
但不要在同一字段上同时使用 $min 和 $max，因为多个更新操作符针对同一字段时，MongoDB 的执行顺序没有明确保证，结果会变得不确定。如果确实需要同时约束一个字段的上下界，可以考虑使用聚合管道更新，或者拆分成两次更新操作。
二、与 $set 的差异及典型应用场景
$set 是无条件赋值，无论当前字段是什么，都会直接覆盖成新值。$min 和 $max 则是有条件写入，只有在满足大小关系时才覆盖。这一点在并发场景下尤其重要。假设有两个请求分别想把价格记录更新为 20 和 5，使用 $set 时，最终值完全取决于谁最后执行；使用 $min 时，不管执行顺序如何，最终都会稳定在 5。
下面用一段对比代码来说明：
// 使用 $set 可能互相覆盖
db.products.updateOne({ _id: 1 }, { $set: { price: 20 } });
db.products.updateOne({ _id: 1 }, { $set: { price: 5 } });
// 使用 $min 保证价格只向更小值收敛
db.products.updateOne({ _id: 1 }, { $min: { price: 20 } });
db.products.updateOne({ _id: 1 }, { $min: { price: 5 } });
在 $min 的例子中，如果先写入 20，再写入 5，最终 price 为 5；如果先写入 5，再写入 20，20 不会覆盖 5，最终仍是 5。这种单向收敛特性非常适合记录历史最低价。电商平台经常会展示商品的历史最低价，通过 $min 可以保证任何一次价格采集都不会把更低的记录错误抬高。
另一个典型场景是游戏玩家历史最高分。每次玩家结束一局游戏时，服务端只需要执行一次 $max 更新，就能确保数据库中的最高分不会被较低的分数覆盖：
db.players.updateOne(
{ playerId: "p-908" },
{ $max: { bestScore: 15400 } }
);
类似地，传感器网络中的最低温度、设备运行时的最低电压、水位监测的历史最低水位，都可以用 $min 来维护。这种写法比先查询当前值再判断是否更新的逻辑更简洁，同时减少了应用与数据库之间的网络往返。
三、嵌套字段与数组字段中的规则
如果目标字段位于嵌套文档中，可以使用点路径来指定。例如玩家文档中有一个 stats 内嵌文档，包含 highScore 字段，更新时可以这样写：
db.players.updateOne(
{ _id: 3001 },
{ $max: { "stats.highScore": 99 } }
);
如果 stats 文档或 highScore 字段不存在，MongoDB 会创建必要的结构并写入新值。点路径让 $min 和 $max 可以灵活地作用于内嵌对象，但要注意路径中不能包含空字符串或点号作为字段名的一部分，如果字段名本身包含点号，可以使用 $getField 或聚合管道来处理。
数组字段的情况则容易产生误解。$min 和 $max 对数组字段执行的是整体比较，而不是逐元素比较。假设文档中有一个数组 scores: [10, 20, 30]，执行以下更新：
db.exams.updateOne(
{ _id: 1 },
{ $min: { scores: 25 } }
);
在 BSON 类型比较顺序中，数组排在数字之后，数字 25 小于数组 [10, 20, 30]，因此 $min 会认为新值更小，于是把整个 scores 字段替换成数字 25。这通常不是我们期望的结果。如果希望更新数组中的某些元素，需要结合 arrayFilters 使用位置操作符。例如要把 scores 数组中所有大于 5 的元素都降低到 5，可以这样写：
db.exams.updateOne(
{ _id: 1 },
{ $min: { "scores.$[elem]": 5 } },
{ arrayFilters: [ { "elem": { $gte: 5 } } ] }
);
这段代码中的 arrayFilters 会匹配所有满足 elem >= 5 的数组元素，然后对每个匹配的元素执行 $min 操作。因此数组 [10, 20, 30] 最终会变成 [5, 5, 5]。如果数组元素是内嵌文档，也可以使用更复杂的过滤条件。需要区分的是，$min 本身不会遍历数组，必须借助 arrayFilters 才能达到逐元素更新的效果。
四、类型比较、并发与最佳实践
边界值更新依赖 BSON 类型比较顺序。MongoDB 对不同类型的值有固定的排序，大致顺序是 MinKey < Null < 数值 < 字符串 < 对象 < 数组 < BinData < ObjectId < Boolean < Date < Timestamp < RegExp < MaxKey。这意味着如果字段当前值是字符串“abc”，使用 $max: 100 时，数字 100 排在字符串之前，因此新值不大于当前值，更新不会发生；而使用 $min: 100 时，100 小于“abc”，字段会被替换成数字 100。这种跨类型的比较可能会导致边界操作结果与预期完全相反。
因此，最佳实践是保证同一字段在所有文档中具有一致的数据类型。可以在集合上启用 Schema Validation，限制目标字段必须为数字类型，从源头避免类型混杂带来的边界误判。如果历史数据已经存在类型不一致的情况，可以先做数据清洗，将非数字值统一为 null 或删除字段。
并发方面，$min 和 $max 的比较与写入是在单个文档内原子完成的，能够有效避免同一文档上的读-改-写竞态。但单文档原子更新不能替代跨文档事务。例如库存扣减需要同时更新库存文档和订单文档时，仅靠 $min 无法保证两个文档的一致性，此时应该使用多文档事务。对于单文档内多个字段的边界约束，$min 和 $max 结合使用已经足够。
最后，性能上 $min 和 $max 与 $set 相比没有明显差异，更新操作的主要成本在于定位文档和维护索引。建议在过滤条件上建立合适的索引，以加快匹配速度。如果更新操作频繁且目标字段被索引，索引维护可能带来额外开销，但这与操作符类型无关。合理使用 $min 和 $max 可以减少应用层的读取压力，同时降低并发覆盖的风险。