一句话总结
Snowflake的系统设计面试，不是考察你对特定技术的掌握程度，而是衡量你在面对复杂业务需求时，构建可靠、可扩展、可维护系统的思维框架；不是罗列架构组件，而是通过深挖权衡取舍来展现你驾驭分布式系统复杂性的能力；不是追求一次性完美设计，而是展现你迭代演进、处理边界条件和故障场景的系统性思考。
适合谁看
这篇裁决适合所有计划冲击Snowflake高级软件工程师（Senior SDE）、首席软件工程师（Staff SDE）及以上职位的候选人。如果你认为系统设计仅仅是画几张框图、列举常用组件，如果你在面对开放式问题时，倾向于立即给出单一技术方案而非探索多种可能性及其优劣，如果你在阐述设计时，无法深入到数据一致性、故障恢复、性能瓶颈和成本优化等深层考量，那么你的判断大概率是错误的。
本文旨在纠正这些偏差，为你提供在Snowflake严苛面试环境中脱颖而出的正确判断标准。你将不再被动地等待面试官提问，而是主动引导讨论，展现你作为未来系统架构师的决策力和洞察力。
Snowflake系统设计面试的核心目标是什么？
大多数候选人误以为Snowflake的系统设计面试是在测试他们对最新技术的追捧程度，或是对特定开源组件的熟悉度。这是一种根本性的误判。面试官真正的目的，不是看你能在白板上写出多少技术名词，而是评估你在没有现成答案的复杂场景下，如何运用第一性原理去分析问题、定义边界、迭代方案，并最终做出有依据的架构决策。
在一次SDE Staff的面试Debrief会议中，面试官的反馈清晰地指出：“这位候选人虽然熟悉Kafka和Kubernetes，但当被问及为什么选择这些技术而非其他时，他无法给出令人信服的、基于数据一致性模型或故障恢复策略的深层考量。他只是在堆叠名词，而不是在构建思想。”
Snowflake作为一家以云原生数据仓库为核心业务的公司，其产品天然要求极高的可扩展性、弹性、高可用性和数据一致性。因此，面试的核心并不是你对特定语言或框架的精通，而是你对分布式系统设计原则的深刻理解和应用能力。这不是让你背诵CAP定理的定义，而是让你在设计一个全局一致的元数据服务时，如何权衡可用性与一致性，并清晰地阐述你的选择背后的业务驱动力。
例如，在设计一个大规模数据摄取系统时，不是简单地说“我会用一个消息队列”，而是要具体说明你将如何处理数据乱序、重复消息、背压（backpressure）以及如何保证端到端的数据完整性，即使在部分节点宕机的情况下。你的设计必须体现出对Snowflake核心业务场景的深刻洞察：海量数据、复杂查询、多租户隔离、近乎无限的弹性伸缩。
面试官会通过一系列追问，深挖你设计中的每一个决策。你选择一个NoSQL数据库，他们会问你它的数据模型如何支持你的查询模式，以及在数据量达到PB级时，如何进行高效的分片和索引。你提出一个微服务架构，他们会问你服务间如何通信、如何管理依赖、如何处理分布式事务，以及在服务故障时如何实现优雅降级。这不是一个“对错”的测试，而是一个“深度与广度”的测试。
你必须展现出，你不仅能看到森林，也能看到每一棵树的纹理和根系。在一次关于设计一个高并发API Gateway的讨论中，一位资深面试官的评价是：“这位候选人很好地覆盖了负载均衡、认证授权等基础功能，但他未能深入探讨在流量突增时如何进行智能限流、如何处理慢查询对整个系统的影响，以及如何通过熔断机制来防止级联故障。他不是在设计一个健壮的系统，而是在罗列一个功能列表。”
如何识别并解构Snowflake的系统设计问题？
许多候选人在面对开放式系统设计问题时，往往急于给出第一个想到的方案，或者直接套用网上常见的“万能模板”。这种做法的根本错误在于，你没有花时间真正理解问题的核心需求、约束条件以及潜在的扩展性挑战。Snowflake的面试官给出问题后，期待的不是你立刻动笔画图，而是你通过提问来收敛问题空间。
这不是面试官在考你猜谜语，而是模拟真实世界中产品经理与工程师之间的协作模式。一个高级工程师，其价值在于能将模糊的需求转化为清晰可执行的技术方案。
识别并解构设计问题的第一步，是明确“Who, What, When, Where, Why, How Much”。不是盲目接受问题描述，而是主动澄清：目标用户是谁？核心功能有哪些？非功能性需求，如QPS（每秒查询数）、延迟、可用性、数据量级、数据一致性模型要求是什么？预算和时间线有何限制？例如，当被要求“设计一个短链接服务”时，糟糕的候选人会直接开始画URL生成器和数据库表结构。而优秀的候选人会提问：“这个服务预计每天产生多少短链接？
短链接的有效期是多久？是否需要支持自定义短链接？是否存在地理位置限制？流量峰值是多少？是否需要支持点击量统计和分析？数据一致性要求是最终一致性还是强一致性？”每一个问题都在帮助你构建一个更精确的问题模型，而不是一上来就陷入细节。
在一次关于设计“一个大规模实时分析仪表盘”的面试中，一位候选人开场就直接画了Kafka、Spark Streaming、ClickHouse的架构图。当面试官问及数据新鲜度（data freshness）的要求时，他才意识到他设计的方案可能无法满足秒级延迟的需求。他犯的错误是，不是先定义问题和约束，而是先抛出解决方案。
正确的做法是，在确定了核心需求（例如，用户需要查看过去5分钟内的数据，延迟不能超过3秒）之后，再基于这些约束来选择技术栈。这是一种从需求到方案的逆向工程思维，而非从技术到需求的顺向匹配。
另一个常见的陷阱是，候选人往往只关注“Happy Path”的设计，而忽略了异常情况和边界条件。在Snowflake，数据处理的鲁棒性是核心。因此，在解构问题时，你必须主动思考：系统在面对网络分区、节点故障、数据丢失、恶意攻击时会如何表现？如何处理数据重复或丢失？
如何确保数据管道的幂等性？不是被动等待面试官问你错误处理机制，而是主动提出并阐述你的异常处理策略。例如，设计一个分布式事务系统时，不是只考虑两阶段提交协议，而是要深入探讨在协调者或参与者崩溃时，如何通过补偿事务、幂等操作或更高级的共识算法（如Paxos/Raft）来保证最终一致性，即使系统面临部分故障。这种对系统“韧性”的考虑，才是Snowflake SDE面试所看重的深度。
在Snowflake面试中，架构决策的优先级如何排序？
在系统设计面试中，面试官并非寻求一个“完美”的答案，因为在现实世界中，完美的设计是不存在的，只有在特定约束下的“最优解”。大部分候选人都会犯的错误是，他们无法清晰地阐述自己的决策逻辑，或者在不同属性（如性能、成本、可用性、可维护性）之间摇摆不定。
这反映出对系统设计本质的误解：它不是技术罗列，而是持续的权衡取舍。在Snowflake，由于其商业模式和技术栈的特殊性，某些优先级是隐性的，但至关重要的。
首先，可扩展性（Scalability）和弹性（Elasticity） 几乎总是排在首位。Snowflake的核心价值在于其计算和存储分离的架构，允许用户根据需求独立扩展资源，并按需付费。因此，你的设计必须体现出对这种云原生、弹性伸缩理念的深刻理解。不是设计一个在固定硬件上运行的系统，而是设计一个能够无缝扩展到数千节点、处理PB级数据的系统，并且能够快速地按需缩容。
例如，在设计一个数据湖查询引擎时，糟糕的候选人会提出一个固定大小的Hadoop集群。而优秀的候选人会考虑如何利用云服务（如S3作为存储层），如何通过无服务器计算（如Lambda或Kubernetes上的按需Pod）实现计算资源的弹性，以及如何通过元数据管理确保数据的一致性视图，即使底层计算资源频繁变化。在一次招聘高级SDE的HC会议上，一位候选人因为在设计高并发日志系统时，无法阐述其组件如何在面对100倍流量峰值时动态伸缩，而被直接否决。Hiring Manager明确指出：“他没有理解云原生弹性扩展的精髓，他的方案在Snowflake的场景下是不可接受的。”
其次，数据一致性（Data Consistency）和可靠性（Reliability） 优先级极高。Snowflake的核心是数据，任何对数据完整性和准确性的妥协都是致命的。这不意味着所有场景都需要强一致性，但你必须清楚地知道何时需要哪种一致性模型，以及如何实现它。
不是简单地选择一个数据库，而是要解释你如何处理并发写入、如何进行数据校验、如何从故障中恢复而不丢失数据。例如，在设计一个分布式事务系统时，不是仅仅停留在2PC（两阶段提交）或3PC，而是要深入讨论如何处理网络分区导致协调者与参与者之间的通信中断、如何通过幂等操作和补偿事务来保证最终一致性，以及如何利用版本控制和乐观锁来处理并发更新。你必须展现出对数据生命周期管理的全面思考，从摄取到存储，再到处理和查询，每一步都不能有数据丢失或损坏的风险。
最后，成本效益（Cost-Efficiency）和可维护性（Maintainability） 也是Snowflake看重的因素。在云环境中，资源是按使用量计费的。因此，你的设计不仅要高性能，还要高效。不是一味追求最快的响应速度，而是要找到性能与成本之间的最佳平衡点。
同时，一个复杂的系统最终需要人来维护，因此可观测性（Observability）、可测试性（Testability）和清晰的架构文档都是衡量设计质量的重要标准。例如，在设计一个大规模数据管道时，不是只考虑数据吞吐量，还要考虑如何通过数据分层存储来优化成本（热数据在SSD，冷数据在对象存储），如何通过监控和告警系统快速发现问题，以及如何通过自动化测试来确保每次部署的稳定性。一位资深工程师在内部技术评审中曾强调：“一个无法被有效监控和维护的系统，即使性能再好，也是一个定时炸弹，最终会消耗团队大量的精力。”你的设计必须体现出对全生命周期成本的考量，而不是仅仅局限于功能实现。
如何有效沟通你的设计思路？
许多候选人在系统设计面试中，最大的问题不是设计本身不好，而是无法清晰、结构化地沟通他们的设计思路。他们往往在白板上画一堆框图，然后就开始罗列技术名称，或者陷入某个组件的细节而忽略了全局。
这是一种沟通上的失败，因为它没有替面试官做判断，反而让面试官去猜测你的意图。在Snowflake，作为SDE，你不仅要能设计系统，更要能向跨职能团队（如产品经理、其他工程师、甚至高层领导）清晰地阐述你的设计决策及其背后的逻辑。
有效沟通设计思路，不是简单地画图，而是要遵循一种自顶向下、逐步深入的结构化方法。首先，从高层架构开始：用一个简洁的框图展示系统的主要组件、它们之间的关系以及数据流向。这不是让你画一张全景图，而是让你构建一个能够快速传达核心思想的抽象模型。
在这个阶段，你不需要关注具体的数据库类型或消息队列实现，而是要聚焦于系统的宏观结构和核心功能。例如，设计一个推荐系统，你可以先画出用户行为收集层、特征工程层、模型训练层、实时推荐服务层，以及它们之间的数据流。
其次，深入探讨关键组件和技术选择：在高层架构清晰之后，面试官会期望你能够对其中一个或几个关键组件进行详细阐述。此时，不是简单地罗列你将使用的技术，而是要解释你选择这些技术的原因，以及这些选择背头所做的权衡。这包括：为什么选择Kafka而不是RabbitMQ？为什么使用PostgreSQL而不是Cassandra？
你的解释必须基于具体的非功能性需求（如吞吐量、延迟、一致性模型、成本、运维复杂性等），而不是基于个人偏好或“大家都这么用”。例如，在设计一个数据摄取管道时，糟糕的候选人会说：“我用Kafka，因为它很快。”而优秀的候选人会说：“我选择Kafka作为核心消息队列，因为它提供了高吞吐量、持久化存储和顺序保证，这对于我们处理实时事件流至关重要。同时，Kafka的Consumer Group模型能够支持多个消费者并行处理数据，满足我们下游多个服务对数据订阅的需求，而不是简单地依赖一个集中式的消息代理。”
最后，主动讨论边界条件、故障场景和未来的扩展性：这是区分平庸与卓越的关键。不是被动等待面试官提问系统的弱点，而是主动识别并阐述你的设计在哪些方面存在局限性，以及你将如何应对这些挑战。这包括：系统在极端负载下的表现如何？如果某个核心组件宕机，系统会如何降级？如何处理数据不一致？如何通过监控和告警来快速发现问题？未来的扩展方向是什么？
例如，在设计一个分布式文件存储系统时，糟糕的候选人会忽略文件元数据一致性问题，也不会考虑在大规模文件删除时的性能影响。而优秀的候选人会主动提出：“我的设计在元数据服务上可能存在单点瓶颈，我会考虑引入Raft共识协议来提高其可用性。同时，对于大规模小文件存储，我会考虑聚合存储以减少元数据开销。未来，如果需要支持跨区域复制，我会在数据同步和冲突解决机制上进行额外设计。”这种前瞻性和批判性思维，才是Snowflake希望看到的SDE的沟通能力。你不是在呈现一个完美的设计，而是在呈现一个可演进、可维护、可应对复杂挑战的思维过程。
Snowflake SDE的薪资构成与职业发展路径如何？
在硅谷，Snowflake为高级软件工程师（Senior SDE）提供的薪资包极具竞争力，通常由基础工资（Base Salary）、股权奖励（RSU）和年度奖金（Bonus）三部分构成。对于一个经验丰富的Senior SDE，基础工资通常在$180,000到$250,000之间。股权奖励（RSU）是总薪酬中占比最大、也是最具吸引力的部分，通常在$300,000到$600,000之间，分四年归属（vesting），每年归属四分之一。
年度奖金则根据个人绩效和公司业绩，通常占基础工资的10%到15%。因此，Snowflake高级SDE的总现金补偿（TC）通常在$400,000到$700,000的区间。这个薪资结构反映了Snowflake对顶级工程人才的重视，以及其作为快速成长型公司的股权激励策略。
Snowflake的SDE职业发展路径，不是简单地沿着层级晋升，而是鼓励工程师在技术深度和影响力广度上同时发展。其职业阶梯通常从SDE I/II开始，向上晋升至Senior SDE、Staff SDE、Principal SDE，直至Distinguished SDE。每个层级都对工程师的技术贡献、领导力、跨团队协作能力和战略视野有明确的要求。
Senior SDE 的核心职责是独立完成复杂的设计和实现任务，并在小团队内提供技术指导。他们不再仅仅是代码的执行者，而是需要对所负责模块的架构设计、性能优化和可靠性负责。这不是简单地完成分配的任务，而是主动识别并解决技术挑战，推动项目进展。
晋升到 Staff SDE 级别，意味着工程师的影响力不再局限于单个项目或团队。他们通常会负责跨团队的技术方向，领导大型项目的架构设计，解决公司层面的技术难题。
在一次内部晋升评审中，一位Staff SDE被赞赏的原因是：“他不仅带领团队成功交付了一个核心组件，更重要的是，他通过技术布道和跨团队协作，统一了公司内部多个数据管道的错误处理策略，极大地提升了整体系统的鲁棒性。”Staff SDE不是简单的“技术经理”，而是通过技术领导力来驱动变革。
再往上的 Principal SDE 和 Distinguished SDE，则需要工程师在更广阔的领域展现出深远的技术影响力，包括定义公司的技术愿景、引领行业技术趋势、解决最复杂的跨领域技术挑战。他们通常是某个技术领域的专家，他们的决策能够影响整个公司的技术走向。
这并非单纯的技术堆栈掌握，而是对技术与业务结合的深刻理解，以及在战略层面做出正确判断的能力。他们不是被动地执行指令，而是主动地创造和引领。
总而言之，Snowflake的SDE职业发展，不是让你成为一个“全栈工程师”，而是鼓励你在某个领域深耕细作，同时扩展你的影响力半径。它不是一个纯粹的个人贡献者路径，而是要求工程师在技术深度的基础上，不断提升其在团队、部门乃至公司层面的技术领导力和影响力。
准备清单
- 系统设计基础理论复习： 重新审视分布式系统基础原理，如CAP定理、数据一致性模型（强一致性、最终一致性、因果一致性）、共识算法（Paxos, Raft）、分布式事务（2PC, Saga）、消息队列设计、负载均衡策略、缓存机制、API设计原则。这不是死记硬背概念，而是理解其在实际场景中的应用和权衡。
- Snowflake产品和架构研究： 深入了解Snowflake的云原生数据仓库架构，包括计算和存储分离、弹性工作负载、微分区（Micro-partitions）、多集群共享数据、数据复制和故障转移等核心特性。理解这些特性如何影响你对高可用、可扩展、多租户系统的设计。
- 云原生服务熟练度： 熟悉主流云服务（AWS, Azure, GCP）中的计算、存储、网络、数据库和消息服务。不是仅仅知道名称，而是理解它们各自的优势、劣势、适用场景以及如何在设计中进行组合。
例如，S3/Blob Storage作为廉价持久存储，Lambda/Cloud Functions作为无服务器计算的快速原型，Kafka/Kinesis作为高吞吐消息队列。
- 实际项目经验梳理： 回顾你过去参与过的复杂系统设计项目，提炼出其中的挑战、你做出的关键决策、面临的权衡、以及最终的成果。准备好详细阐述这些经验，并能深入讨论你设计中的优点和缺点，以及如果重来你会如何改进。
- 系统性拆解面试结构（SDE面试手册里有完整的Snowflake分布式事务处理系统实战复盘可以参考）： 练习如何从模糊的需求开始，通过提问澄清需求，定义系统边界，确定非功能性需求，然后自顶向下地进行架构设计，最后讨论异常处理、扩展性和监控。
- 模拟面试与反馈： 找有经验的SDE进行模拟面试，并获取详细反馈。特别关注沟通方式、对权衡取舍的阐述、以及对追问的应对能力。这不仅仅是技术练习，更是沟通和压力应对的训练。
- 白板和图示练习： 熟练使用白板或在线绘图工具清晰地表达你的设计，包括数据流、组件交互、API接口等。图示不是目的，而是辅助你清晰沟通的工具。
常见错误
- 错误一：缺乏对问题的深入理解与澄清
BAD: 面试官：“设计一个新闻推荐系统。” 候选人：“好的，我打算用Kafka收集用户行为，然后用Spark处理，再存到Cassandra，用Elasticsearch做搜索。”
GOOD: 面试官：“设计一个新闻推荐系统。” 候选人：“好的。首先，我想澄清一些关键需求：这个系统是为实时推荐（如首页Feed流）还是离线推荐（如每日邮件）？用户规模和新闻量级分别是多少？数据新鲜度要求是秒级还是分钟级？是否需要支持多语言或多区域？个性化程度要求多高？是基于内容的推荐还是协同过滤？”
裁决： 糟糕的候选人急于展示技术栈，却忽略了设计的基础——需求。这不仅反映了缺乏产品思维，更暴露出无法在模糊信息中定位核心问题的弱点。正确的判断是，一个合格的SDE在接到任务时，不是立刻动手，而是通过提问来收敛问题空间，确保所有后续设计都建立在对业务和技术约束的清晰理解之上。你不是一个代码执行者，而是一个问题解决者。
- 错误二：技术方案罗列，缺乏权衡与深入分析
BAD: 面试官：“为什么你选择Kafka而不是RabbitMQ？” 候选人：“因为Kafka吞吐量更高，更适合大数据场景。”
GOOD: 面试官：“为什么你选择Kafka而不是RabbitMQ？” 候选人：“我选择Kafka，不是因为其单纯的吞吐量优势，而是因为它提供了高持久性、顺序保证和分区特性，这对于我们处理大规模、高并发的用户行为事件流至关重要。与RabbitMQ的智能broker模式不同，Kafka的dumb broker设计允许消费者自主管理消费偏移量，这在构建数据回溯和复杂流处理管道时提供了更大的灵活性，且避免了broker端的瓶颈。
虽然RabbitMQ在复杂路由和消息优先级方面有优势，但这并非当前场景的核心需求。在故障恢复方面，Kafka的复制机制也提供了更好的数据安全性。这是基于对我们系统需求中高吞吐、高持久性、消费者灵活性的优先级判断。”
裁决： 许多候选人仅仅停留在“知道什么技术能做什么”的层面，却无法深入解释“为什么在特定场景下选择这种技术而非另一种”。面试官想看到的，不是你对技术文档的复述，而是你基于系统需求、非功能性约束和技术权衡做出的有依据的决策。你必须展现出对不同技术优劣的深刻理解，以及在特定场景下，如何平衡性能、成本、复杂性、可维护性等多个维度。
- 错误三：忽略异常处理、边界条件和可观测性
BAD: 候选人在白板上画了一个完整的系统流程图，所有组件都正常工作。当面试官问及“如果数据库连接池耗尽怎么办？”时，候选人停顿，然后说：“那就增加连接池大小。”
GOOD: 候选人设计了一个分布式服务。面试官：“如果你的推荐服务突然响应变慢，你如何发现并处理？” 候选人：“首先，不是被动等待用户反馈，而是主动通过Prometheus收集服务延迟、错误率、QPS等关键指标，并设定阈值进行告警。当延迟超过SLO（服务等级目标）时，告警会触发。
我会首先检查服务的依赖项，例如数据库或缓存是否存在瓶颈。同时，我会利用分布式追踪系统（如Jaeger）来定位慢请求的具体环节，是外部API调用、内部RPC还是数据库查询。如果问题持续，可以考虑启用限流和熔断机制，防止问题扩散到其他服务，并确保核心功能至少能够降级可用。我还会预设自动扩容策略以应对短期流量冲击，并定期进行压力测试以验证系统在极端负载下的行为。”
- 裁决： 许多候选人倾向于描绘一个理想化的“Happy Path”系统，却忽略了真实世界中无处不在的故障和异常。一个健壮的系统设计，必须包含对各种失败模式的考量，以及如何通过监控、告警、容错和降级机制来保证系统的韧性。你必须展现出，你不仅能设计功能，更能设计一个能够持续运行、自我修复的系统。忽视这些，你的设计在Snowflake这样的企业级平台面前，形同虚设。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
- Snowflake系统设计面试中，我应该重点展示哪些分布式系统知识？
你应重点展示对分布式事务、数据一致性模型、共识算法、高可用架构、弹性伸缩策略和故障恢复机制的深刻理解。这不是简单地背诵理论，而是能在具体设计场景中，清晰地阐述这些概念如何指导你的技术选择和权衡。例如，在设计一个跨地域数据复制系统时，你需要讨论如何平衡数据新鲜度与一致性，以及在网络分区时如何处理冲突。
面试官会深挖你对这些核心概念的实际应用能力，而不是仅仅停留在教科书定义。一个常见的误区是只关注“性能”，而忽略了在Snowflake这种数据密集型环境中，“数据正确性”和“系统韧性”优先级更高。你必须展现出对这些深层原理的掌握，并能解释它们如何影响你的架构决策。
- 在面试过程中，如果我遇到一个不熟悉的技术栈或领域，应该如何应对？
遇到不熟悉的技术栈，正确的做法不是假装知道，也不是回避问题，而是展现你的学习能力和解决问题的通用框架。首先，承认你不熟悉该特定技术，但可以基于已知原理进行推断。例如，你可以说：“我对Kafka的集群管理细节可能不完全熟悉，但根据我对分布式消息队列的理解，它应该会采用Leader-Follower模型来保证可用性和数据一致性，并且通过分区机制实现水平扩展。
”其次，你可以提出一系列探索性问题，以缩小信息差距，并基于现有信息提出一个高层面的、原理性的解决方案。面试官更看重你如何思考和解决问题，而不是你是否拥有所有知识。展现你如何通过提问、假设、验证的迭代过程来逼近答案，才是他们真正想看到的。
- Snowflake对SDE的沟通能力有何特殊要求？我应该如何准备？
Snowflake对SDE的沟通能力要求极高，不仅仅是口头表达清晰，更重要的是结构化思维和跨职能协作能力。你必须能够将复杂的技术概念，以简洁明了的方式传达给不同背景的听众。准备时，你需要练习如何自顶向下地阐述设计，先宏观后微观；如何明确定义问题和假设；如何清晰地解释技术选择背后的权衡取舍，而非简单罗列；
如何主动识别并讨论设计的局限性、异常处理和未来扩展性。这不仅是关于“说什么”，更是关于“如何说”以及“如何引导讨论”。例如，在解释一个复杂的数据管道时，不是直接跳到代码实现，而是先用业务语言描述其解决的问题，再用高层架构图展示组件，最后再深入到关键技术细节，并主动提问面试官最感兴趣的区域。你需要像一个产品负责人一样，持续替面试官做判断，而不是让他们被动地接收信息。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。