2026 项目管理平台服务器租用测评：OpenProject 工作包与甘特负载 7 项对比 + 选型全解

2026 项目管理平台服务器租用测评：OpenProject 工作包与甘特负载 7 项对比 + 选型全解

项目平台的资源账要拆成三块算

给 OpenProject 报服务器配置，最常见的错法是拿「账号数 × 一个系数」去套。这个算法在读多写少、对象结构扁平的系统上勉强能用，放到项目管理平台上会失真得厉害。原因是这类平台的负载并不均匀摊在用户身上：一个五十人的团队，日常可能只有十几个人在改工作包，但每到周一早上和迭代评审前，所有人同时打开甘特图和列表页，负载曲线是一个陡峭的尖峰，而不是一条平线。按平均在线人数乘系数，算出来的配置在尖峰时刻必然不够。

真正决定配置的是三块互不相同的资源账。第一块是工作包与自定义字段，它吃的是数据库的查询宽度和缓冲区；第二块是代码仓库与附件，它吃的是磁盘容量和顺序读写；第三块是后台作业队列，它吃的是 CPU 和数据库连接，而且作业库与业务库同源，会跟录入操作抢同一个实例。三块的增长曲线完全不同：工作包按项目数近似线性增长，仓库按提交历史累积增长，作业队列按导出和通知的频率周期性抖动。用同一个系数去乘，必然有一块被严重低估，通常被低估的是仓库和后两块。

可以先用一个粗算的骨架把量级框住：内存约等于 Puma 进程数乘单进程常驻，加作业 worker 数乘单 worker 常驻，加 PostgreSQL 的 shared_buffers，加操作系统页缓存预留。以五十人团队、二十人并发在线、单个项目一千五百个工作包、三年累积八十 GB 代码仓库为参照，整机内存落在 16 到 32 GB 是常见区间，而不是很多人以为的 4 GB 就够。这个区间属于经验估算，实际要按自定义字段数量和仓库规模往上抬。

还有一个常被忽略的维度是「谁来用」。研发团队的工作包更新频繁、自定义字段多、仓库活跃；行政和业务团队的项目管理平台更像一个带甘特的登记簿，写入少、查询多、字段固定。同样是五十人，前者的数据库压力和磁盘增长可能是后者的三到五倍。所以在报配置之前，先问清楚这套系统里有多少比例的人是工程师、有多少项目挂了代码仓库，比问「多少人用」有用得多。

机位放在哪里，同样会改变这本账。团队集中在华南，把机器放在同城节点，克隆仓库和提交附件这几件重活走内网或同城链路，体感差别明显；团队分布在多地，就要看机房的 BGP 多线接入质量，而不是只看单线带宽数字。项目管理平台不像视频和下载那样吃带宽，但它对延迟的抖动很敏感——甘特图一次页面加载要发几十个静态资源请求，链路抖一下，用户体验就从「流畅」掉到「卡顿」，而这种卡顿在带宽监控上完全看不出来。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

Ruby on Rails 的进程账：Web worker 与作业 worker

OpenProject 跑在 Ruby on Rails 上，这一点决定了它的内存模型和 PHP 那一类「请求结束进程就回收」的系统完全不同。Rails 是常驻进程模型：一个应用进程启动之后，框架代码、ActiveRecord 的模型定义、已加载的类、预热后的字节码，全都躺在内存里不走。Puma 在 cluster 模式下 fork 出多个 worker 进程，每个进程独立处理请求，进程之间不共享业务对象，只共享写时复制的只读内存页。这意味着 worker 数量直接等于内存的倍数关系，加一个 worker 就是加一份常驻。

单进程常驻内存的经验区间是三百到六百 MB，装的插件越多、自定义字段定义越复杂、加载的本地化语言包越多，越靠上限。这个数字的含义很直接：四个 Puma worker 光应用进程就吃掉 1.2 到 2.4 GB，还没算数据库和操作系统。很多人在 4 GB 的机器上开四个 worker，跑起来看着能用，一旦有人打开甘特图触发大批量对象实例化，进程内存翻倍，系统的内存回收机制直接把 worker 杀掉，表现就是「页面偶尔报错，刷新一下又好了」，而日志里只有一行不起眼的进程退出记录。

后台作业是另一批进程。OpenProject 用 Rails 侧的队列消费导出、邮件通知、仓库同步、附件缩略图这类任务，worker 进程的常驻内存在二百到五百 MB 区间，每个 worker 内部的并发线程数决定它同时抓多少任务。作业 worker 不是越多越好：每个线程占一条数据库连接，连接数上去之后 PostgreSQL 的每连接内存（工作内存、排序内存、临时缓冲区）成倍放大，反而拖慢整体。十个线程的 worker 在数据库侧的等效开销，可能比多开一个应用进程还高。

所以进程账要这么算：先定并发在线人数，按每人 0.15 到 0.3 个 Puma worker 的经验比例估 worker 数，五十人在线大约四到六个；再按导出和通知的频率定一到两个作业 worker，导出频繁的团队给两个、每个两到四线程；最后留出 25% 到 35% 的余量给峰值和内存碎片。把这三项加上数据库，才是应用侧真实的内存需求。此外 Ruby 的垃圾回收对内存不敏感，进程跑久了常驻会缓慢抬升，部署时要配一个基于内存阈值的平滑重启，别等到撑爆才处理。

工作包与自定义字段：行数不大，查询很宽

工作包是 OpenProject 的核心对象，任务、缺陷、需求、里程碑都是它，靠类型字段区分。十万级的工作包记录对 PostgreSQL 来说是很小的表，单表几 GB 的规模在现代硬件上根本不构成压力。所以「数据库是不是太小了」这个问题，在项目管理平台上几乎从来不是瓶颈所在。真正的瓶颈是查询的宽度，以及由宽度带来的连接数放大。

自定义字段是最容易被低估的一块。每加一个自定义字段，工作包列表页的查询就多一次关联或者一次类型转换。字段少的时候，优化器还能走索引；字段多到二十个以上，列表页要一次性取出全部列做渲染，执行计划会从索引扫描退化成宽表扫描，再加上排序和分页，单次查询的耗时能从几百毫秒抬到一秒以上。这是经验区间里的常见现象，不是数据库性能不够，是查询本身变宽了，而变宽的成本主要落在内存和临时文件上。

更麻烦的是按自定义字段筛选。如果这个字段没有建索引，筛选就是全表扫描加类型转换；如果建了普通 B-tree 索引，字符串型字段的前缀匹配未必用得上；如果字段值存在 JSONB 里，还得看有没有对应的表达式索引。一个「按客户等级筛出未关闭工作包」的日常操作，在字段设计不当时可以吃掉一秒以上的数据库时间，十个人同时点就是十秒的 CPU 时间堆在同一个实例上，前台所有请求一起变慢。

还有一个隐蔽的放大效应：自定义字段会跟着版本走。每导入一批历史数据、每合并一次项目模板，字段的取值基数就变大，索引的选择性变差，优化器可能干脆放弃索引。到了这一步，加内存只能缓解缓存未命中，解决不了执行计划本身的问题。

可执行的规则是：自定义字段总数控制在十五个以内，其中参与高频筛选的不超过五个，且这五个必须有索引；列表页默认展示列不超过八列，其余放进详情页按需加载；用保存的视图固化常用筛选组合，让优化器有机会复用执行计划；字段类型尽量统一，布尔和枚举优于自由文本，因为前者的索引选择性稳定。项目数量多、字段又杂的团队，宁可多开几个项目类型，也不要在同一个类型上堆三十个字段。

甘特与依赖重算：一次渲染吃两种资源

甘特图和时间线视图是 OpenProject 里最重的页面，没有之一。它要在一次请求里把整个项目的工作包、层级关系、前置后继关系、版本、里程碑全部取出来，在内存里排布时间轴，计算关键路径，再把结果渲染成带依赖连线的图形。这个过程同时吃 CPU 和内存，而且两者是叠加的：对象越多，实例化越慢，内存峰值越高；内存压力一大，垃圾回收触发更频繁，CPU 又被回收线程吃掉一部分。

量级上可以这样估：单项目五百个工作包、一千条关系，一次甘特渲染的额外内存峰值在一百到三百 MB 区间，CPU 时间在零点五到两秒；工作包涨到两千、关系涨到五千，渲染时间会到三到八秒，内存峰值可能翻倍。这是经验估算，具体取决于服务器的单核性能和 Ruby 的垃圾回收参数。关键在于它不是线性增长：关系密度上去之后有明显的放大效应，因为排布算法要在关系图上反复遍历。

项目层级是另一个放大器。三层以内的项目树，递归查询还能接受；到了五层以上，每一层都要做一次父子关系展开，查询次数按层数累加，而甘特图又要求一次性拿到全量数据，不能像列表页那样分页截断。跨项目依赖更贵，它把两个项目的对象图连在一起，缓存命中率直接掉下来，原本能靠缓冲区兜住的热点数据被挤出内存。一个只在个别项目上出现的跨项目依赖，可能拖慢整个实例的甘特响应。

对应的做法是：甘特图只对当前项目加载，不做全局甘特；项目层级控制在四层以内，更细的拆分用版本和看板表达；跨项目关系只保留真正影响排期的少数几条；给甘特接口单独设一个较短的超时，超时就降级成列表视图，而不是让请求一直挂着把 worker 占死。五十人规模下，甘特页面的并发数通常只有个位数，但每一次都很重，配置时要按「少数重请求」而不是「多数轻请求」来留余量，这也是为什么单核主频比核心总数更值得关注。

代码仓库是磁盘增长最快的那一块

项目管理平台挂上 Git 或 SVN 仓库之后，磁盘的增长曲线会跟别的东西彻底分开。工作包是文本，一万条也就几十 MB；附件是用户上传的文档和截图，增长可预期；代码仓库不一样，它保存的是全部历史，每一次提交、每一个分支、每一个被删掉却留在历史里的大文件，都永久占着空间。一个中型代码库三五年下来到几十 GB 很常见，多仓库并行开发的团队到几百 GB 也不稀奇。

这里有个容易被忽略的细节：仓库的磁盘占用不等于工作区的大小。一个工作区两百 MB 的仓库，带着多年分支历史和曾经误提交的二进制文件，裸库可能有好几 GB。团队如果习惯把构建产物、设计源文件、数据库导出一并提交，膨胀速度会快一个数量级。按经验区间估，每十个活跃仓库、三年累积，裸库总量在一百到四百 GB 是常见量级；如果历史上有人提交过几百 MB 的安装包，单仓库超过十 GB 也不意外。

仓库还不只是占容量，它同时吃 CPU。仓库浏览要遍历提交树，差异渲染要做行级比对，一次大提交的比对能把一个核跑满好几秒。这些操作走的是应用进程，跟甘特图抢同一批 Puma worker。仓库越大、历史越深，单次浏览越慢，而且这个慢没法靠加内存解决，只能靠限制单次比对的输出行数、关掉大文件的文本渲染、把仓库浏览的并发压低。仓库数量多的团队，浏览器里同时开着五个差异页面，就等于五个重请求压在同一个进程池上。

所以磁盘要单独规划：系统盘、数据库盘、仓库盘、附件盘分开挂，仓库盘用容量优先的固态盘，不要跟数据库挤在同一块盘上抢随机写。备份策略也要分开，数据库适合每天全量加增量，仓库更适合做裸库镜像或者定期打包归档，冷仓库定期迁到低速大容量存储。容器化部署时，仓库目录必须挂持久卷，否则容器一重建，几年的提交历史就没了，这类事故在小团队里并不罕见。

还有一个与选型直接相关的判断：仓库盘能不能单独扩容。托管商如果只支持整机加盘、不支持独立加一块数据盘，那么仓库涨到临界点时，唯一的出路是整机迁移，而整机迁移意味着所有服务一起停机。这一点在签合同前问清楚，成本远低于事后补救。

后台作业与主库同源，意味着导出会拖慢录入

OpenProject 的作业队列是 Rails 侧的队列，较新版本把作业表直接落在 PostgreSQL 里。这个设计的好处是不用额外维护缓存中间件，部署简单、备份一致；代价是作业和业务查询共用同一个数据库实例，抢同一份共享缓冲区、同一批磁盘 IOPS、同一组连接。导出报表、批量发通知、同步代码仓库这些任务，看起来是「后台」，实际上跟前台录入在同一个资源池里打架，只是延后发生而已。

最典型的场景是月度汇报前的批量导出。一个二十万行的工作包导出成表格文件，要做全表扫描、关联自定义字段、序列化输出，整个过程占用一到两个核、持续三十秒到两分钟。期间 PostgreSQL 的缓冲区被这次顺序扫描冲刷一遍，原本常驻在内存里的热点索引页被挤出去。紧接着前台有人保存工作包，本来几毫秒的更新，因为要重新从磁盘读索引页，变成几十毫秒；并发再高一点，录入的 P95 响应能抬到平时的两到五倍。用户体感是「系统下午突然变慢」，而监控上 CPU 和磁盘都没有跑满，只有缓冲区命中率掉了一截。

邮件通知也有类似效应，只是更隐蔽。工作包状态一变就触发通知，一次批量变更（比如批量关闭一个迭代的遗留项）会瞬间产生几百条通知作业，每条都要查收件人、渲染模板、写发送记录。这些写操作和业务更新争同一批行锁和预写日志的写入带宽，表现出来是「批量操作卡住，单个操作正常」。这类问题很难从系统监控上看出来，只能从数据库的锁等待和写入延迟上找。

处理思路有限但有效：导出类作业并发限制在一到两个，并且尽量放在夜间窗口跑；给长查询设语句超时，超时就中断而不是让它一直占着连接；通知改成批量聚合发送，不要一条工作包变更就发一封；作业 worker 的连接池单独配置，别跟前台请求共用一个池，避免后台把前台的连接额度吃光。如果数据库压力实在大，可以考虑把作业表迁到独立实例，但那会增加部署和备份的复杂度，五十人规模通常不必要，八十人以上、导出频繁的团队值得评估。

OpenProject 的硬件六维：Rails 进程、仓库与查询宽度

CPU 这一维要看单核性能而不是核数。Rails 的请求处理以单线程为主，一个请求再多的核也用不上，甘特渲染、差异比对、报表序列化都是单线程跑完。所以同样是八核，主频高的那台表现明显更好，这在甘特页面上的差距尤其明显。经验起点是四到八 vCPU，五十人团队、甘特使用频繁的场景建议六核以上；核心再多，收益会被内存带宽和数据库 IO 吃掉，不如把钱加在内存上。

内存是这一套系统里最该舍得给的一项。前面算过，四个 Puma worker 加两个作业 worker 就要三到五 GB，加上 PostgreSQL 的共享缓冲区（建议给到物理内存的 25% 左右）、每连接的排序与工作内存、操作系统页缓存（仓库和附件读写非常依赖它），十六 GB 是五十人规模的舒适起点，三十二 GB 能覆盖三年内的增长。八 GB 只能算勉强能跑，一旦并发上来就会看到交换分区被频繁使用，而交换对常驻进程模型的伤害是成倍的。

固态盘要按容量和随机读写两个指标看。数据库盘需要稳定的随机写，仓库盘需要大容量和顺序读，两者最好物理分开。经验区间是数据库盘留出库大小三倍以上的余量（含预写日志、临时文件、备份中转），仓库盘按现有裸库总量乘二起步。机械盘在项目管理平台上不推荐做主存储，只适合做冷归档，因为数据库的随机写会把机械盘的寻道时间放大成明显的响应抖动。

带宽的需求比很多人想的小。项目管理平台的页面是文本加少量图片，五十人日常办公的出口带宽在十到二十 Mbps 独享就够，真正的尖峰来自仓库克隆和备份外传。一次全量克隆几十 GB 的仓库，能把百兆口跑满十几分钟，这段时间里其他人的页面加载会明显变慢。所以带宽要按「峰值事件」估而不是按平均值估，出口建议五十 Mbps 以上，并且要确认计费方式是按带宽包月还是按流量计费，后者在备份外传频繁时账单会失控。

电力和机位是托管场景的固定项。一台双路塔式或 2U 机架服务器，整机功耗在三百到五百瓦区间，加上交换机、KVM、备份设备，一个机柜位的实际取电要按 1.5 倍估。机位按 1U 或 2U 算，注意有些机房对单机位功率有上限，配置双路高功耗处理器加多块硬盘时要提前确认，否则上架后被限功率，性能表现会跟预期差一截，而且这种落差很难在验收时立刻发现。

项目管理平台六种部署形态对比

下面这张表把自建侧常见的六种形态列在一起，最后一行放 SaaS 作对照，一共七行。之所以要放在一起看，是因为选型失败往往不是选错了单机配置，而是选错了形态：该拆的没拆，或者在不该拆的时候拆了。表里的配置起点都是经验区间，不是官方要求，OpenProject 官方文档并没有给出硬性的硬件门槛，任何声称「官方要求多少核多少 G」的说法都值得怀疑。

读这张表的顺序应该是：先看自己的规模落在哪一档，再看主要瓶颈是不是自己最怕的那个，最后看风险项能不能接受。单机一体化最大的价值是省事，最大的风险是仓库和数据库抢盘；应用与数据库分离解决的是资源争抢，代价是多一跳网络和一份运维；Web 与作业 worker 拆分是性价比最高的一步，只多一台小机器就能把导出对录入的影响压下去，而且这台小机器可以很便宜。

容器化加外部 PostgreSQL 适合已经有编排平台的团队，但要特别注意持久卷：数据库、仓库、附件三处都必须挂持久卷，任何一处落在容器临时层，重建即丢数据。挂独立仓库存储这一步，很多团队前期不做，等到仓库涨到几百 GB 再迁，停机窗口会很难排。低配起步后纵向扩容是最常见的路径，前提是托管商能给到同机型加内存、加盘的通道，否则「扩容」实际上是迁移，而迁移的停机时间往往是扩容的十倍。

升级与迁移：停机窗口怎么估

OpenProject 的版本升级不是换一个安装包那么简单，它伴随数据库结构迁移，而且对 PostgreSQL 的大版本有兼容矩阵要求。跨大版本升级必须按官方给出的顺序逐级走，不能从很老的版本一步跳到最新版，中间每一级都要跑一次迁移。这一点在选型时就要问清楚：托管商能不能指定 PostgreSQL 的大版本，后续能不能在原地升级这个大版本，还是只能重装系统再导入。前者是运维便利，后者是每次升级都要规划一次停机。

停机窗口的估算可以拆成三段：备份、迁移、验证。备份是把数据库和仓库都做一份一致的快照，数据库十 GB 量级在固态盘上通常几分钟，仓库按容量算，一百 GB 在千兆内网传输要十五到二十分钟，这是经验区间。迁移是跑数据库结构变更和数据回填，耗时跟库大小和变更复杂度相关，十 GB 的库常见在二十到六十分钟，五十 GB 可能到两到四小时。验证是启动应用、跑冒烟测试、检查附件和仓库可达，通常留三十到六十分钟。

三段加起来，再乘一个一点五左右的安全系数，才是可以对外承诺的窗口。十 GB 库、一百 GB 仓库的一次跨小版本升级，四到六小时是比较现实的估算；如果要跨 PostgreSQL 大版本，还要加上导出导入或者原地升级工具的时间，八到十二小时也不奇怪。跨大版本最稳的做法是新建实例、导入数据、切换入口，而不是在原机上原地升级，因为原地升级失败之后回滚很困难，尤其是数据已经按新结构写进去之后。

降低停机影响的实操手段有几个：先在快照或者克隆实例上完整演练一遍，把每一步的实际耗时记下来，用真实数据而不是拍脑袋定窗口；附件如果放在对象存储，迁移可以提前做增量同步，把切换时的增量压到很小；切换前把应用置为只读，让用户知道什么时候不能写，比事后解释有效得多；保留旧实例一段时间不删，出问题能快速切回。这些准备的成本，远低于一次升级失败后从备份恢复的成本，而后者往往还伴随着数据丢失的争议。

还有一层与租用形态相关的判断：如果用的是按月租用的物理机，升级期间可以临时再租一台同配置机器做切换，成本只有一个月租金，窗口压力立刻小很多。如果用的是包年且不能临时加机的方案，就得把升级窗口排在业务低谷，通常是小长假前，而这又跟项目管理的迭代节奏冲突。选型时把「能不能临时加一台机器」问清楚，比纠结单台配置高低更影响长期体验。

项目管理平台落单前的五个核对项

第一项，PostgreSQL 的大版本与扩展权限。OpenProject 的数据库只支持 PostgreSQL，这一点跟多数 PHP 类系统不同，没有第二种选择。所以要确认托管商能不能给到指定的大版本，而不是「随便装一个最新版」。大版本决定升级路径和兼容矩阵，装错了版本，后续每次升级都要先做大版本迁移。另外要确认有没有权限装扩展，三元组相似度检索、全文检索这类能力都依赖扩展，没有权限就得绕远路。

第二项，磁盘能不能分。系统、数据库、仓库、附件四类数据放在同一块盘上，短期能跑，长期必然互相拖累。要确认能不能挂第二块、第三块数据盘，能不能独立扩容某一块盘而不动其他。这一项决定了后面三年的扩容自由度，比 CPU 主频重要得多。

第三项，备份与快照的能力边界。要问清楚是整机快照还是目录级快照，快照保留几天，能不能自助恢复，恢复是恢复到新机器还是覆盖原机。项目管理平台的数据价值在于历史，一次误删的工作包层级或者误推的仓库分支，只能靠备份找回。没有自助恢复能力的方案，等于把风险全压在服务商身上。

第四项，带宽口径与出网计费。要区分「独享带宽」和共享峰值，要确认仓库克隆、备份外传是否计入流量。很多方案标称带宽很大，但出网按流量计费，一次全量备份就能产生可观的账单。这一项在项目管理场景里尤其容易踩，因为仓库体积大、备份频繁。

第五项，扩容与迁移的实际路径。要确认加内存是停机加还是热插，加盘要不要重装，换机型是同机房同代际还是有代差。同机房同代际意味着可以走内网迁移，几小时能完成；跨机房跨代际意味着一整晚的停机。这五项核完再去看报价单，顺序不要颠倒，参数漂亮但版本对不上、盘分不开、备份恢复没演练过的机器，便宜也是有代价的。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

自建与 SaaS 的分界线在哪

讨论自建还是订阅，最容易陷入的误区是只比订阅费和服务器租金。真实的成本结构里，服务器只占一部分，运维人力、升级窗口、故障响应、备份验证才是长期的大头。按经验区间估，一套五十人规模的自建 OpenProject，日常维护大约需要零点二到零点五个运维人力，主要是版本升级、备份巡检和偶发的性能排查；把这部分折算成成本，再加上机器和带宽，才是可比的口径。

第一条分界线是自定义字段的深度。SaaS 方案的自定义字段通常是有限几个、类型固定、不能建表达式索引；自建可以随便加字段、加索引、改查询。当一个团队的自定义字段需求超过十个、并且需要按其中多个字段做组合筛选和报表时，SaaS 的边际体验会快速下降，这时候自建的价值才真正体现。反过来，如果字段需求在五个以内、报表靠导出到表格处理，SaaS 完全够用。

第二条分界线是代码仓库的归属。把仓库挂在项目管理平台上，本质上是把代码资产和项目数据放在同一套备份与权限体系里。自建能控制仓库的存储位置、备份节奏、访问策略；SaaS 受限于平台能力和网络条件，大仓库的克隆体验往往不理想。团队如果已经有独立的代码托管，项目管理平台只做任务追踪，这条分界线的权重就低很多。

第三条分界线是数据属地与合规要求。有些行业要求项目数据留在境内特定区域，或者要求能出具数据存放位置的证明，这时候自建（或私有部署）是硬约束，成本比较就没有意义了。第四条是规模拐点：三十人以下，SaaS 的人均成本通常低于自建加运维；八十人以上、且重度使用甘特与自定义字段的团队，自建的边际成本开始占优。这个拐点是经验估算，会随团队的技术能力和使用强度浮动，不能当成硬指标。

还有一条容易被忽略：升级节奏的掌控权。自建意味着可以选择什么时候升级、升到哪个版本、先在哪台机器上验证；SaaS 意味着跟着平台的节奏走，某天早上打开发现界面变了、字段类型改了、接口行为调整了。对流程稳定的团队这是小事，对把项目管理平台当成生产系统、接口对接了内部系统的团队，这是实打实的风险。判断标准很简单：如果这套系统停一天，业务会不会停？会停，就值得为掌控权付溢价。