线性规划（Linear Programming）解决的是在一组线性等式或不等式约束下，求线性目标函数最大值或最小值的问题。很多业务场景如生产排期、原料配比、运输调度、金融投资组合，都能抽象成这种数学模型。Node.js 本身没有内置求解器，但通过 npm 生态可以加载纯 JavaScript 实现或 WebAssembly 编译的求解库，直接在服务端完成优化计算。选择合适的建模方式和求解器，是保证结果正确与响应速度的第一步。

从业务问题到线性规划模型

线性规划模型由三个部分构成：决策变量、目标函数和约束条件。以一个小型家具厂为例，假设每天可用的木材总量固定，生产桌子和椅子分别消耗不同数量的木材与工时，同时每种产品有最低产量要求。决策变量可以设为 x 表示桌子数量，y 表示椅子数量；目标函数为最大化总利润，比如每张桌子利润 80 元，每把椅子利润 50 元，则目标为 80x + 50y。约束条件包括木材消耗不超过上限、工时不超过上限，以及 x 和 y 不能为负数。

在 Node.js 中，不需要把模型写成数学公式再手工求解，而是用对象结构描述这些关系。大多数求解库都接受类似 JSON 的模型定义：variables 里声明每个决策变量的系数，constraints 里声明资源上限或下限。这种建模方式的好处是，业务规则可以直接从数据库或配置中心读取后动态生成，适合需要频繁调整约束的运营系统。

需要注意的是，线性规划要求目标函数和所有约束都是线性的。如果出现 x 乘以 y、变量的平方或分段计费，就不能直接使用基础线性规划求解器，需要转成整数规划、二次规划或引入 0-1 变量做线性化。先确认问题是否线性，比急着写代码更重要。

Node.js 可用求解库及选型对比

Node.js 生态里常用的线性规划库主要有三类。第一类是纯 JavaScript 实现的 javascript-lp-solver，零原生依赖，安装简单，支持连续型线性规划和整数规划，适合变量数量在几十到几百级别的场景。第二类是基于 GLPK 的 WebAssembly 版本 glpk.js，性能比纯 JS 高出一个量级，能处理更大规模问题，但 API 更底层，需要自行组装矩阵数据。第三类是通过原生模块绑定系统 GLPK 或其他求解器的包，例如 node-glpk，计算速度最快，但要求服务器预装对应动态库，部署复杂度较高。

从工程角度看，如果只是给内部管理系统增加一个排产建议功能，变量和约束总数不超过一两百，javascript-lp-solver 足够稳定且容易调试。如果每天要跑上万次求解，或者模型达到上千变量，就应优先评估 glpk.js 或独立计算服务。还要考虑整数规划的求解时间：纯 JS 的分支定界在整数变量较多时可能明显变慢，此时 WebAssembly 方案优势更突出。

下面用一个表格汇总三者差异。表格中的求解规模是经验值，实际表现与约束稀疏程度、整数变量数量有关，不能当作绝对边界。

选型时还要关注维护状态和文档质量。javascript-lp-solver 的 README 示例清晰，适合快速上手；glpk.js 需要理解 GLPK 的模型格式，但社区活跃，遇到问题容易搜索到解决方案。

完整示例：多约束资源分配问题求解

假设有一个生产计划场景：工厂生产两种产品 A 和 B，每件 A 利润 60 元，每件 B 利润 90 元。生产 A 需要 2 单位钢材和 1 小时机器时间；生产 B 需要 4 单位钢材和 3 小时机器时间。每天可用钢材 240 单位，机器时间 180 小时。为了保持产品线稳定，A 至少生产 10 件，B 至少生产 5 件。目标是最大化总利润。

使用 javascript-lp-solver 建模时，目标函数系数放在变量的 profit 字段中，资源消耗放在 constraints 对应的变量字段里。约束名可以自定义，但变量名必须与模型中的变量字段一致。下面的代码给出完整求解过程。

const solver = require('javascript-lp-solver');
const model = {
  optimize: 'max',
  opType: 'max',
  constraints: {
    steel: { max: 240 },
    machine: { max: 180 },
    minA: { min: 10 },
    minB: { min: 5 }
  },
  variables: {
    A: { profit: 60, steel: 2, machine: 1, minA: 1, minB: 0 },
    B: { profit: 90, steel: 4, machine: 3, minA: 0, minB: 1 }
  }
};
const result = solver.Solve(model);
console.log(JSON.stringify(result, null, 2));

这个模型里，constraints 中的 steel 和 machine 表示资源上限，minA 和 minB 表示最低产量下限。变量 A 的 steel 值为 2，表示生产一件 A 消耗 2 单位钢材；minA 为 1 表示 A 计入最低产量约束。求解后 result.feasible 为 true 时，result.A 和 result.B 就是最优生产数量，result.result 是最大总利润。返回对象中的 bounded 表示目标函数是否有界，如果为 false，通常说明约束缺少上限，模型存在无界解。

如果产品数量必须为整数，可以在模型中增加 ints 字段，把 A 和 B 标记为整数变量。求解器会自动切换到分支定界方法，但计算时间可能增加。对于大多数生产排产问题，整数结果比连续结果更符合实际，建议一开始就加入整数约束。

const integerModel = {
  optimize: 'max',
  opType: 'max',
  constraints: {
    steel: { max: 240 },
    machine: { max: 180 }
  },
  variables: {
    A: { profit: 60, steel: 2, machine: 1 },
    B: { profit: 90, steel: 4, machine: 3 }
  },
  ints: { A: 1, B: 1 }
};
const integerResult = solver.Solve(integerModel);
console.log('整数最优解:', integerResult.A, integerResult.B);
console.log('最大利润:', integerResult.result);

从输出可以看到，整数约束下最优解可能不再是线性松弛的简单取整。比如连续解可能生产 45 件 A 和 37.5 件 B，而整数解会在 45 和 37 或 44 和 38 之间寻找真正的最优组合。这个差异正是运筹优化中整数规划的价值所在。

结果解读与常见异常排查

求解返回的 result 对象通常包含 feasible、bounded、result 以及每个变量的取值。feasible 为 false 表示约束集合没有交集，模型不可行。常见原因是业务规则冲突，例如最低产量要求超过了资源上限能承受的最大产量。此时应检查 constraints 中的 max 与 min 是否同时过紧，或者是否把资源系数写反。

无界解通常表现为 bounded 为 false，目标值趋向无穷大。线性规划中如果只约束了资源下限而没有上限，目标又是最大化利润，求解器就可能无限增加变量取值。修复方法是为每个决策变量添加合理的 max 上限，或者检查 constraints 中是否遗漏了关键资源限制。

还有一类隐蔽问题是约束名称不匹配。javascript-lp-solver 依赖变量中出现的约束字段来累加约束值，如果 constraints 里定义了 steel，但某个变量的对象里漏写了 steel 字段，该变量就不会被计入钢材消耗，导致结果看似可行但违反实际业务约束。建议在建模后用断言检查所有约束字段都出现在每个相关变量中，或者封装一个校验函数。

灵敏度分析方面，可以通过小幅调整某个约束的 max 或 min 值重新求解，观察目标函数变化。比如把机器时间从 180 提高到 200，如果总利润增幅明显，说明机器时间是当前瓶颈；如果利润几乎不变，则说明瓶颈在钢材或其他约束。这种手工影子价格分析对业务决策很有帮助。

生产环境部署与性能优化

把线性规划求解嵌入 Node.js 服务时，需要注意求解器是同步还是异步。javascript-lp-solver 的 Solve 方法是同步执行，如果模型规模较大或整数变量较多，会阻塞事件循环。对于 API 服务，建议把求解任务放到工作线程或独立进程中执行，避免影响其他请求。Node.js 的 worker_threads 模块可以方便地实现这一点。

另一个优化点是缓存。如果大量请求的模型参数只在小范围内变化，可以按约束组合做结果缓存，或者保存上一轮求解结果作为初值。对于需要频繁求解的运营系统，使用 Redis 缓存最优解并设置短过期时间，能明显降低计算压力。

在安全方面，模型数据通常来自前端或外部系统，必须做严格的数值校验。资源上限、利润系数、约束系数不能为负数或非法值，否则可能导致求解异常甚至死循环。此外，求解超时也要设置，虽然 javascript-lp-solver 没有内建超时机制，但可以通过外部定时器终止工作线程。

如果业务规模持续扩大，超过单机纯 JS 求解能力，可以考虑将求解逻辑迁移到独立优化服务，例如基于 Python 的 PuLP 或 OR-Tools，Node.js 通过 HTTP 或消息队列调用。这样既能保留 Node.js 的业务灵活性，又能借助更成熟的优化生态处理大规模问题。