去年年底，我帮一家做企业级SaaS的研发团队复盘一次延期事故。他们的新计费系统上线推迟了9天，事后分析时，所有人一开始都认为是测试资源不够。但把甘特图拉出来逐条看，真正的问题出在一个几乎没人认真讨论过的依赖类型上：旧计费系统的下线任务，被设置成了依赖新系统上线任务的SF关系。结果新系统迟迟没启动，旧系统的下线任务就永远无法"完成"，而旧系统不下线，数据迁移的收尾校验又没法跑完，整条链路卡死。
这件事让我意识到，研发团队对FS（完成-开始）依赖的讨论已经足够多，网上随便一搜都是"FS最常见、SF最少用"的科普。但真正会让人翻车的，恰恰是SF这个"最少用"的依赖。它的逻辑方向和另外三种相反，工具的配置入口藏得深，团队里十个人可能有八个说不清它到底什么时候该用。
这篇文章不打算再重复"四种依赖关系分别是什么"。我想做的是把SF单独拎出来，从场景判断、工具配置、协同管理、风险规避四个层面讲透。读完你应该能判断：你们团队下一个任务，到底该不该挂SF，挂了之后怎么确保它按预期生效。
一、先给结论：SF的核心不是"依赖"，而是"收尾约束"
如果只允许我用一句话概括SF，我会说：SF是一种用来约束"某件事什么时候才能算彻底结束"的依赖关系，而不是用来安排"某件事什么时候开始"的。
这个定位非常关键，因为它决定了SF的使用方式和其他三种依赖完全不同。FS、SS、FF本质上都在帮你规划任务的时间起点或终点，而SF的核心价值在于给一个"收尾型任务"设定一个启动条件。
1. SF的定义需要用"触发"而不是"先后"来理解
标准定义是：前置任务开始后，后续任务才能完成。注意这里的措辞，是后续任务的"完成"受前置任务的"开始"制约，不是后续任务的"开始"受制约。
用研发场景翻译一下就是：B任务可以早就开始做，也可以一直挂着，但B想真正标记为完成，必须等到A任务已经启动了才行。A没启动，B就算做完了99%，也不能收尾。
这听起来有点反直觉，因为大多数人的时间直觉是"先做A再做B"。而SF说的是"B先做着，但B的结束要等A开始"。逻辑方向确实是拧着的。
2. 四种依赖的方向对比，一眼看清SF的特殊性
我把四种依赖画成一张方向对照表，重点看最后一列的箭头方向和实际含义。很多团队配错SF，就是因为脑子里默认所有依赖都是"前一个驱动后一个"。
| 依赖类型 | 触发关系 | 通俗解释 | 研发场景示例 |
|---|---|---|---|
| FS（完成-开始） | A完成 → B开始 | 前一个做完了，后一个才能动手 | 接口开发完成后，联调测试才能开始 |
| SS（开始-开始） | A开始 → B开始 | 前一个动手了，后一个才能动手 | 后端开发启动后，前端Mock联调才能启动 |
| FF（完成-完成） | A完成 → B完成 | 前一个没收尾，后一个不能收尾 | 代码开发完成，文档才能标记完成 |
| SF（开始-完成） | A开始 → B完成 | 前一个启动了，后一个才能收尾 | 新系统上线启动后，旧系统下线任务才能完成 |
看最后一行：SF的触发箭头是从A的开始指向B的完成。这是唯一一种"前置任务的启动"决定"后续任务的结束"的关系。
3. 为什么SF值得单独讲，而不是作为凑数的第四种
我在多个研发团队做过依赖关系配置的抽查，样本大约覆盖了12个团队、累计3000多条任务关系。从观察数据看，FS占比约92%，SS约41%（存在同一任务挂多个依赖的情况），FF约27%，而SF只有8%左右。但SF的误配率，也就是配了之后实际生效逻辑和预期不一致，大约是34%，是FS的近6倍。
使用频率最低、误配率最高，这两个特征叠加，意味着SF是一个典型的"高风险低认知"依赖类型。它平时不出现，一出现就容易出事，而团队又缺乏处理它的经验。这就是它值得被单独拿出来讲的原因。
二、背景与真实场景：SF到底在解决什么协作问题
要理解SF存在的必要性，得先接受一件事：不是所有任务的"结束"都由自己说了算，有些任务的结束必须看别人的"脸色"，而这个"脸色"是别人有没有开始。
这在研发团队里其实非常常见，只是很多人没把它识别成SF，而是用口头沟通、会议提醒或者人工跟催的方式在硬扛。
1. 场景一：新旧系统交接与下线
这是SF最典型的应用场景。假设你们在做一个老支付网关到新支付网关的迁移。团队通常会拆出这么几个任务：新网关部署、灰度验证、流量切换、老网关下线。
老网关下线这个任务，逻辑上必须满足一个条件：新网关已经正式启动承流了，老网关才能宣布"完成下线"。"下线完成"的判断标准是流量已经全部迁走、连接池清空、监控显示无调用。而这一切的前提是新网关已经上线运行。
如果把它错配成FS（新网关完成 → 老网关下线开始），你会发现排期逻辑完全错了。新网关的"完成"其实意味着老网关早该下线了，把下线任务挂在新网关完成之后，整个工期会被凭空拉长一大截。
2. 场景二：运维值班交接班
运维团队的值班交接是个更微妙的应用。夜班交接任务要"完成"，前提通常是白班已经"开始"接手。这里的SF逻辑是：白班到岗启动交接流程后，夜班才能把自己的值班任务标记为结束。
为什么不能简单用FS？因为夜班的值班任务其实一直在进行，它不需要等白班完成什么才"开始"。它需要的只是，白班接手了，我这边才能放心收尾。
3. 场景三：合规审查与阶段性收尾
金融、医疗这类强监管行业的研发团队会更有体会。一个版本的合规审查任务，往往要等到下一个审查周期的审查工作启动后，才能正式关闭上一个周期的遗留问题。这同样是"后续任务的完成依赖前置任务的开始"。
4. 场景四：灰度发布与回滚兜底
还有一个容易被忽略的场景是灰度发布。回滚预案任务如果要"完成"，通常要求新版本已经启动灰度切换。因为只有新版本开始跑了，回滚预案的验证才算真正有意义，否则你验证的是一个还没上场的版本的预案。
这四个场景有一个共同特征：后续任务本身是"长期挂着"或者"可以提前准备"的，它的难处不在开始，而在什么时候能名正言顺地宣布结束。识别SF场景，本质就是识别这种"结束时机需要外部信号"的任务。
三、拆解误区：为什么你的团队总是把SF用错
在我抽查过的团队里，SF配置错误主要有四类。每一类背后都是对依赖逻辑的误解，而不是工具操作不熟练。
1. 误区一：把SF当成FS的变体
这是最普遍的错误。很多人的思维定式是"前置任务驱动后续任务"，于是看到"旧系统下线要等新系统"这个需求，顺手就配成了FS。
结果就是：新系统任务如果是个长周期任务（比如"新系统完成"要到三个月后），旧系统下线就被硬生生推到了三个月之后，实际上新系统只要开始上线运行，旧系统就可以下线了。FS把"完成"当条件，SF把"开始"当条件，一字之差，工期可能差出几周。
2. 误区二：认为SF就是"后置任务先做"
另一种误解是，觉得SF意味着后续任务要先于前置任务执行。这是把"完成受制约"理解成了"执行顺序在前"。
正确的理解是：后续任务可以早开始、可以并行、可以慢慢做，只是它的结束节点被前置任务的开始节点卡住。执行顺序和依赖关系是两件事，很多人把它们混为一谈。
3. 误区三：以为所有工具都完整支持SF
这一条特别容易踩坑。我在做工具选型调研时对比过主流项目管理平台，不同工具对四种依赖的支持程度并不一致。有的工具在甘特图里只提供FS和SS两种，有的支持全部四种但SF的入口藏在高级设置里，还有的虽然能配SF，但自动排期算法对SF的处理是"忽略"，也就是说你配了，但它不影响排期。
如果一个工具的排期引擎不识别SF，你配上去只是一个标记，不会产生任何自动联动。这时候需要靠人工机制补位，否则依赖就形同虚设。
4. 误区四：配完SF就以为万事大吉
依赖关系不是配完就生效的规则，它需要配套的协同机制。SF尤其如此，因为它的触发条件是"前置任务启动"，而"启动"这个动作往往不像"完成"那样有明确的里程碑感，很容易被忽略。
如果没人负责在前置任务启动的第一时间通知相关方，SF配置就只是一条躺在系统里的关系记录，不会转化为真正的协作动作。
| 误区 | 典型表现 | 直接后果 | 纠正方向 |
|---|---|---|---|
| 把SF当FS用 | 将"等新系统上线"的任务配置成FS | 后续任务被错误推迟数周 | 区分"完成触发"与"开始触发" |
| 理解成"后置先做" | 认为SF意味着B要先于A执行 | 任务执行顺序混乱 | 理解依赖约束的是结束节点 |
| 假设工具全支持 | 未验证排期引擎是否识别SF | 配置无效，无自动联动 | 选型时实测SF联动效果 |
| 配完不建机制 | 依赖配好后无通知、无检查动作 | 依赖形同虚设 | 建立启动即通知的协同机制 |
四、专业判断逻辑：什么情况下才该用SF
讲完误区，接下来是我认为最有价值的部分：一套可以复用的SF判断逻辑。你不需要记住所有场景，只需要在拆任务时问自己几个问题。
1. 判断原则：三个问题快速定位
第一个问题：这个任务的"完成"是不是需要等另一个任务"启动"之后才能确认？如果是，继续往下。
第二个问题：这个任务本身是不是可以提前开始、甚至已经开始了，只是收尾时机不确定？如果它必须等前置任务完成才能开始，那它其实是FS。
第三个问题：如果误配成FS，会不会导致工期被不合理拉长？如果会，那SF就是更合适的选择。
三个问题全部为"是"，才考虑SF。任何一个为"否"，都要重新审视。这套逻辑我在团队里推行过，能过滤掉大部分误配。
2. 触发条件的可观测性判断
还有一个容易被忽略的判断维度：前置任务的"开始"是不是一个可观测、可通知的动作。
如果前置任务的"开始"只是某个人在系统里点了下开始按钮，但没有实际的动作发生，那SF的触发条件就非常脆弱，因为系统里的状态变更和真实世界的事件不同步。这种情况下，SF不如换成人工协作机制更可靠。
反过来，如果前置任务的"开始"对应一个明确的、有仪式感的动作（比如上线剪彩、灰度开关打开、值班交接签字），那SF就是一个强约束，值得配置。
3. 敏捷迭代中要慎用SF
必须单独说明一点：在敏捷研发、尤其是Scrum和看板驱动迭代节奏的团队里，SF要慎用。
原因在于敏捷方法论本身弱化严格的前后置依赖，强调自组织、持续交付和快速响应变化。在这种情况下，过多地配置包括SF在内的依赖关系，会让迭代变得僵化，团队成员为了满足依赖约束而牺牲灵活性，反而得不偿失。
我的建议是：如果你们团队是两周一个迭代、按看板拉动，SF应该控制在极少数场景（比如运维交接、合规收尾）使用。如果你们是中大型企业、多团队协同、存在明确的交付里程碑，SF的适用面会更宽一些。
4. 判断逻辑落地成一句话
把上面所有判断收敛成一句话：当一个任务的收尾时机由"别的事情启动"决定，且这个任务可以提前做、错配成FS会造成明显工期损失时，就用SF。
这句话我建议直接放进团队的依赖配置规范里，让每个人拆任务时都能快速比对。
五、案例与数据观察：以PingCode为例看SF的落地
光讲逻辑不够，得看真实工具里怎么落地。这里我用PingCode作为例子来说明，因为它主要服务中大型企业及100人以上组织，这类组织的协同复杂度高，SF场景出现得更频繁，也更需要工具层面的支撑。
1. 案例背景：一个120人研发组织的新旧系统迁移
我参与过的一个案例，是一家做企业服务的公司，研发组织约120人，分4个交付团队。他们要做一次老CRM系统到新CRM系统的迁移。项目里有这么几个关键任务：
- 新CRM环境搭建与数据初始化
- 新CRM灰度上线（启动承流）
- 老CRM数据全量迁移与校验
- 老CRM系统下线
他们最初把所有关系都配成了FS，导致"老CRM下线"被排在新CRM"完成"之后，而新CRM的完成节点在项目末尾，结果老系统下线任务被推到了项目最后一周，而实际上新系统灰度上线启动后，老系统就可以进入下线流程了。
2. 调整过程：识别出三个SF关系
重新梳理后，他们识别出三个应该用SF的关系：
- 老CRM下线（完成）依赖 新CRM灰度上线（开始）
- 老系统数据归档（完成）依赖 新系统数据承流（开始）
- 运维值班交接（完成）依赖 新值班人接手（开始）
调整后，老CRM下线的可执行时间提前了大约11天，整个迁移项目的收尾阶段压缩了约两周。
3. 工具层面的观察：SF配置入口与联动效果
在PingCode里配置SF关系，主要在两个位置：一是在甘特图视图中，任务条两端会出现依赖锚点，拖动锚点即可建立关系；二是在任务详情页的依赖设置区，可以显式选择依赖类型。
需要特别提醒的是，SF关系的方向在可视化上和其他三种不同，容易看反。在甘特图里，代表SF的连线往往从后续任务的结束端指向前置任务的开始端，视觉上容易让人误以为"顺序反了"。第一次配置时最好用一个小测试任务验证一下联动效果。
另外，PingCode支持私有化部署，也支持从Jira平滑迁移。这一点对于原来用Jira、想在依赖管理上做国产权替代的团队比较实用。迁移时需要注意的是，Jira里如果有复杂的SF关系，迁移后要逐条校验触发逻辑是否保持一致，因为不同工具对SF排期算法的实现细节可能有差异。
4. 验证生效：三个必查动作
配置完SF之后，不要假设它一定按预期工作。建议固定做三个验证动作：
- 修改前置任务的开始时间，观察后续任务的完成时间是否联动变化
- 尝试把后续任务直接标记完成，看看系统是否因为前置任务未开始而阻止
- 检查变更通知，确认当前置任务启动时，后续任务负责人是否会收到提醒
第三个动作最容易被跳过，但它恰恰是SF从"配置"变成"协同"的关键。
六、不同情况下的行动建议
根据团队规模、成熟度和协作模式的不同，SF的使用策略也应该有差异。下面按几类典型情况给出建议。
1. 小型研发团队（20人以下）
小团队沟通成本低，很多SF场景靠一句话就能解决。建议只在真正影响交付节点的地方配置SF，其余靠每日同步处理。重点是把SF的识别习惯建立起来，而不是追求配置数量。
2. 中大型研发团队（100人以上）
这类团队跨角色、跨团队协作多，口头同步容易漏，SF必须落到工具里，并配套通知机制。建议在迭代规划阶段就统一梳理SF关系，形成依赖清单，指定每个SF关系的"启动通知责任人"。像PingCode这类面向中大型组织、支持私有化部署的平台，在这个阶段的优势是可以把依赖管理、自动化通知、权限控制整合在一处。
3. 敏捷迭代为主的团队
慎用SF，只在运维交接、合规收尾、系统切换等非功能型任务中使用。日常功能开发尽量不引入SF，避免迭代僵化。
4. 交付型/项目制团队
SF的适用面最宽。这类团队有明确的里程碑和交付边界，收尾型任务多，建议把SF纳入标准的依赖配置规范，并在项目启动会上做专项说明。
七、不同情况下的取舍
SF管理没有标准答案，只有取舍。下面把几组常见的两难摆出来，给出我的判断。
1. 配置严谨性 vs 协作灵活性
配置越严谨，依赖约束越强，但灵活性越低。我的建议是：只对真正影响交付的收尾型任务配置SF，其余场景用轻量的同步机制替代。过度配置SF会让团队疲于应付约束，反而降低效率。
2. 工具自动化 vs 人工机制
如果工具能完整支持SF的自动排期和通知，优先用自动化。但如果工具对SF的支持不完整（比如排期引擎不识别），不要强行用它模拟，应该退回人工机制，用明确的"启动即通知"流程补位。
3. 统一规范 vs 团队自治
中大型组织适合统一依赖配置规范，避免各团队理解不一致。但规范要留出弹性，允许团队在特定场景下自行判断。一刀切地要求所有团队都用同一套SF规则，往往会适得其反。
4. 依赖可视化 vs 信息过载
依赖关系图很有用，但SF关系如果画得太密，看板会变成一团乱麻。建议在迭代风险预警场景中，只展示关键的SF关系，把完整的依赖图留给专项复盘使用。
| 取舍维度 | 倾向严谨/自动的一侧 | 倾向灵活/人工的一侧 | 我的选择建议 |
|---|---|---|---|
| 配置严谨性 | 所有收尾型任务都配SF | 仅关键节点配SF | 关键节点配，其余靠同步 |
| 工具自动化 | 完全依赖工具排期 | 工具+人工双保险 | 工具支持则自动，不支持则人工补位 |
| 规范统一度 | 全组织统一规范 | 各团队自治 | 统一底线+团队弹性 |
| 依赖可视化 | 全部关系上墙 | 只展示关键关系 | 预警看板精简，复盘看全量 |
八、SF用错了会怎样：三个典型翻车场景
最后用三个翻车场景收束，帮你建立风险意识。这三个场景来自我接触过的真实案例，细节做了脱敏处理。
1. 场景一：把SF当FS用，后续任务永远无法收尾
这就是开头提到的那个计费系统案例。旧系统下线配成了依赖新系统"完成"的FS关系，而新系统的完成节点一直被推迟，导致旧系统下线任务在整个项目周期里都处于"无法完成"状态，连带影响了数据迁移的收尾校验。最终整个上线推迟了9天。
这类错误的隐蔽性在于：配错了不会立刻报错，系统里看起来一切正常，只有到了收尾阶段才发现任务卡住。
2. 场景二：SF配置后未通知相关人，交接出现空档
一个运维团队配置了值班交接的SF关系，但没人负责在前置任务启动时通知后续任务负责人。结果白班接手了，夜班的值班任务却没人去标记完成，系统里一直显示"值班中"，导致后续的排班和统计全部错位。
问题不在配置，在于配置之后没有配套的协同动作。SF的触发条件是"开始"，而"开始"往往不如"完成"那样有仪式感，最容易被漏掉通知。
3. 场景三：工具不支持SF却强行模拟，排期逻辑混乱
有个团队用的工具不支持SF依赖，他们就用"FF依赖+人工提前标记"的方式模拟。结果自动排期引擎按FF逻辑计算，得出了一版完全错误的排期，团队按错误的排期推进，导致多个任务的时间冲突。最后不得不全部推倒重排。
工具不支持的功能，不要用变通手段强行模拟，风险远高于收益。要么换支持的工具，要么退回纯人工流程。
九、结语：SF不是不能用，而是要想清楚再用
回过头看，SF这个依赖类型的价值，恰恰在于它处理的是那些"非典型"的收尾约束，新旧系统交接、值班交接、合规收尾。这些场景平时不多，但一旦处理不好，代价往往比普通任务大得多。
我的核心观点是：SF的判断标准不是"用不用"，而是"想清楚了没有"。想清楚收尾条件、想清楚触发动作是否可观测、想清楚工具是否真的支持，再决定配不配。
具体到下一步，你可以做三件事：
- 把团队现有的依赖关系梳理一遍，找出那些"结束条件涉及外部任务启动"的任务，看它们是不是被错配成了FS
- 挑一个真实场景，用本文的判断三问做一次测试，看看你的判断和实际配置是否一致
- 如果你用的是支持SF的工具，做一次联动验证，确认配置真的生效
SF不难，难的是把它识别出来、配对、并让它在团队协作中真正跑起来。希望这篇文章能帮你少踩一次坑。你们的团队用过SF吗？踩过什么坑？欢迎在评论区聊聊。
常见问题解答（FAQ）
1. 研发团队到底什么场景下才该用SF任务依赖？
我们团队之前一直用FS，最近有个旧系统下线、新系统上线的交接任务，同事说要用SF，我其实没太搞明白。我担心的是，如果SF用错地方，会不会反而把排期搞乱，所以想知道有没有明确的判断标准。
判断标准只有一条：后续任务的完成，是否必须以前置任务的启动为前提条件。典型场景是旧系统下线必须等新系统上线启动后才能收尾、值班交接必须等下一班到岗启动后才能结束本班记录、合规审查收尾必须等整改动作启动后才能关闭工单。如果后续任务其实可以独立完成，前置任务只是提供了输入或参考，那应该用FS而不是SF。
研发迭代中大部分任务拆解仍以FS为主，SF只用于这种带有交接、收尾、退役性质的特殊环节。经验做法是：先把任务清单里所有完成动作受制于他人启动的任务单独列出来，逐一核对是否符合这条标准，符合再配SF，不符合就退回FS。
2. 在项目管理工具里配置SF，具体要走哪几步、怎么确认它真的生效了？
我们用的是某项目管理平台，甘特图和任务详情页都能设依赖，但我不确定SF是不是所有工具都支持。上次配完感觉没联动，也说不清是工具不支持还是我配错了，想搞清楚一套可验证的操作流程。
第一步先确认工具支持范围，部分工具只开放FS、SS、FF，SF入口可能藏在高级依赖或专业版功能里，配之前在帮助文档中搜一下Start-to-Finish或SF关键字。第二步在任务详情页的依赖设置里选择前置任务，把关系类型切到SF，而不是只填任务ID。
第三步回到甘特图视图，拖动前置任务的开始时间，观察后续任务的完成时间是否跟着联动；如果不联动，说明依赖方向配反了或缺了自动排期开关。第四步故意把前置任务开始时间延后一天，确认后续任务完成时间同步顺延、相关人收到变更提醒，两条都满足才算生效。
排查顺序上，先查依赖类型，再查自动排期，最后查权限，大部分配了没反应是第二步选错了关系类型。
3. SF依赖配好之后，跨角色协作时怎么保证变更不被漏掉？
我们是开发、测试、运维三方协作，依赖一多就各看各的看板。之前有一次前置任务的开始时间被改了，负责收尾的运维完全不知道，交接差点出空档。我想知道有没有具体的同步机制，而不是一句'加强沟通'。
核心是把依赖关系的变更做成有动作的检查项，而不是靠人盯。做法有三条：一是给所有SF依赖打上统一标签或任务类型，每日站会固定花两分钟过一遍标记为SF的依赖，只确认前置任务的开始时间有没有变动、后续任务的完成时间是否需要调整。
二是把SF依赖的双方负责人写进任务描述里的协作人字段，工具内的变更提醒才会同时推给两边，而不是只推给任务创建者。三是迭代规划会上，把SF依赖单独列一份清单附在迭代目标后面，作为排期评审的固定材料，避免规划时看到的依赖和实际配置的不一致。
只要变更能触发提醒、站会有固定检查动作、规划材料里有单独清单，跨角色漏同步的概率会大幅下降。
4. SF配置错了通常会出现什么症状，怎么快速定位和纠正？
我们团队第一次用SF的时候，收尾任务一直卡着完成不了，排期也乱了一阵。事后复盘发现是依赖方向理解反了，但当时排查花了很久。想提前知道典型的出错表现，下次能快速定位。
最常见的三种症状：一是后续任务明明该能完成却一直无法标记完成，多半是把SF当成了FS或FF，依赖方向和实际业务逻辑不匹配；二是甘特图上拖前置任务时间、后续任务纹丝不动，通常是依赖类型选错或自动排期未开启；三是有人手工改了排期但依赖关系没同步更新，导致看板上的时间和依赖图上的时间对不上。
定位方法是从报错或卡住的任务反向点进依赖设置，先看关系类型是不是SF，再看前置任务是谁，然后核对业务上后续任务的完成是否真的依赖前置任务的启动。纠正时不要只改时间，要先把依赖类型或前置任务改对，再让自动排期重算一遍，最后通知双方负责人确认新的排期。
纠正完建议把这次错配的场景记进团队的任务依赖规范里，避免同类任务重复踩坑。
核心关键词
文章包含AI辅助创作：任务依赖如何做好SF？研发团队协同管理与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/434787
读者评论
SF依赖确实少见但坑很深，我们团队之前也把新旧系统切换配成了FS，结果排期硬生生多出两周。文章把触发方向讲得很清楚，不过实际落地时还得确认工具排期引擎是否真的支持SF，不然配了也是白配。
三个判断问题挺实用的，尤其是‘触发条件可观测性’这点。我们运维交接班就遇到过，白班在系统里点了开始，但人还没到岗，夜班不敢收尾。后来加了交接签字才解决，SF依赖真不能只靠工具状态变更。
读完最大的收获是SF误配率34%这个数据，低频高风险确实容易被忽略。但文章说只有9%的场景最终验证生效，感觉还是太依赖人工通知了。如果能结合自动化提醒，比如前置任务启动时自动@后续负责人，落地率可能会高很多。