Rust - Tony Bai

标签 Rust 下的文章

Go的简洁性之辩：轻量级匿名函数提案为何七年悬而未决？

六月 3, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/06/03/lightweight-anonymous-func-syntax

大家好，我是Tony Bai。

自2017年提出以来，Go语言关于引入轻量级匿名函数语法的提案（Issue #21498）一直是社区讨论的焦点。该提案旨在提供一种更简洁的方式来定义匿名函数，尤其是当函数类型可以从上下文推断时，从而减少样板代码，提升代码的可读性和编写效率。然而，历经七年多的广泛讨论、多种语法方案的提出与激辩，以及来自核心团队成员的实验与分析，截至 2025年5 月底，官方对该提案的最新立场是“可能被拒绝 (likely declined)”，尽管问题仍保持开放以供未来考虑。近期该issue又冲上Go issue热度榜，让我有了对该提案做一个简单解读的冲动。在本文中，我将和大家一起探讨该提案的核心动机、社区的主要观点与分歧、面临的挑战，以及这一最新倾向对 Go 语言和开发者的潜在影响。

冗余之痛：当前匿名函数的困境

在Go中，匿名函数的标准写法是

func(参数列表) (返回类型列表) {
    函数体
}

虽然这种语法明确且一致，但在许多场景下，尤其是作为回调函数或在函数式编程风格（如配合泛型和迭代器使用）中，参数和返回类型往往可以从上下文清晰推断，此时显式声明则显得冗余。

提案发起者 Neil (neild) 给出了一个经典的例子：

func compute(fn func(float64, float64) float64) float64 {
    return fn(3, 4)
}

// 当前写法，类型声明重复
var _ = compute(func(a, b float64) float64 { return a + b })

许多现代语言，如 Scala ((x, y) => x + y 或 _ + _) 和 Rust (|x, y| { x + y })，都提供了更简洁的 lambda 表达式语法，允许在类型可推断时省略它们。这种简洁性被认为可以提高代码的信噪比，让开发者更专注于业务逻辑。

Go匿名函数常见的痛点场景包括：

回调函数：如 http.HandlerFunc、errgroup.Group.Go、strings.TrimFunc。
泛型辅助函数：随着 Go 1.18 泛型的引入，如 slices.SortFunc、maps.DeleteFunc 以及设想中的 Map/Filter/Reduce 等操作，匿名函数的应用更加广泛，其冗余性也更为凸显。
迭代器：Go 1.23 引入的 range over func 迭代器特性，也使得将函数作为序列或转换器传递成为常态，轻量级匿名函数能显著改善其体验（如 #61898 x/exp/xiter 提案的讨论中多次提及）。正如一些开发者指出的，结合迭代器使用时，现有匿名函数语法会使代码显得冗长。

提案核心：轻量级语法的设想

该提案的核心思想是引入一种“非类型化函数字面量 (untyped function literal)”，其类型可以从赋值上下文（如变量赋值、函数参数传递）中推断得出。提案初期并未限定具体语法，而是鼓励社区探讨各种可能性。

Go team的AI 生成的总结指出，讨论中浮现的语法思路主要可以归为以下几种：

箭头函数风格 (Arrow Function Style): 借鉴 JavaScript, Scala, C#, Java 等。
- 例如：(x, y) => { x + y } 或 (x,y) => x+y
保留 func 关键字并进行变体:
- 例如：func a, b { a+b } (省略参数括号)
- func(a,b): a+b (使用冒号分隔)
- func { x, y | return x < y } (参数列表移入花括号，使用 | 或 -> 分隔)
基于现有语法的类型推断改进:
- 例如：允许在 func(a _, b _) _ { return a + b } 中使用 _ 作为类型占位符。

其核心优势在于：

减少样板代码： 省略冗余的类型声明。
提升可读性（对部分人而言）： 使代码更紧凑，逻辑更突出。
促进函数式编程风格： 降低使用高阶函数和回调的心理门槛。

社区的激辩：争议焦点与权衡

该提案引发了 Go 社区长达数年的激烈讨论，根据 Robert Griesemer 提供的 AI上述总结和整个讨论链，主要争议点包括：

1. 可读性 vs. 简洁性

支持简洁方： 认为在类型明确的上下文中，重复声明类型是视觉噪音。简洁的语法能让代码更易于速读和理解，尤其是在函数式链式调用中。他们认为 Go 已经通过 := 接受了类型推断带来的简洁性。
强调显式方： 以 Dave Cheney 的名言“Clear is better than clever” 为代表，一些开发者认为显式类型声明增强了代码的自文档性和可维护性。他们担心过度省略类型信息会增加认知负担，尤其对于初学者或在没有强大 IDE 支持的情况下阅读代码。Go密码学前负责人FiloSottile 指出，在阅读不熟悉的代码时，缺少类型信息会迫使其跳转到定义或依赖 IDE。Go元老Ian Lance Taylor也表达了对当前显式语法的肯定，认为其对读者而言清晰度很高。

2. 语法选择的困境

这是提案迟迟未能落地的最主要原因之一。社区提出了数十种不同的语法变体，但均未能形成压倒性的共识。

箭头语法 (=> 或 ->)：

优点： 许多开发者因在其他语言中的使用经验而感到熟悉，被认为非常简洁。Jimmy Frasche 的语言调查显示这是许多现代语言的选择。
缺点： 一些人认为它“不像 Go”，=> 可能与 >= 或 <= 在视觉上产生混淆，-> 可能与通道操作 <- 混淆。Robert Griesemer指出，虽然 (x, y) => x + y 感觉自然，但 (x, y) => { … } 对于 Go 而言感觉奇怪。Ian Lance Taylor也表达了对箭头符号的不完全满意，认为在某些代码上下文中可读性欠佳。

保留 func 并简化：

func params {} (省略参数括号)：Ian Lance Taylor 和 Robert Griesemer 曾探讨过此形式。主要问题在于 func a, b {} 在函数调用参数列表中可能与多个参数混淆。
func { params | body } 或 func { params -> body }：Griesemer 在后期倾向于这种将参数列表置于花括号内的形式，认为 func { 可以明确指示轻量级函数字面量。| 用于语句体，-> (可选地) 用于单表达式体。Jimmy Frasche 对此形式的“DSL感”提出异议，认为其借鉴的 Smalltalk/Ruby 风格在 Go 中缺乏相应的上下文。

其他符号：

如使用冒号 func(a,b): expr ，或 _ 作为类型占位符。Griesemer认为 _ 作为类型占位符会产生混淆。

Robert Griesemer 进行的实验表明，func 后不带括号的参数列表 (func x, y { … }) 在实际 Go 代码中看起来奇怪，而箭头符号 (=>) 则“出乎意料地可读”。他后期的实验进一步对比了 (args) => { … } 和 func { args | … }。

3. 隐式返回 (Implicit Return)

对于单表达式函数体是否应该省略 return 关键字，也存在分歧。

支持方： 认为这能进一步提升简洁性，是许多 lambda 语法的常见特性。
反对方： 担心这会使返回行为不够明确，尤其是在 Go 允许多值返回和 ExpressionStmt (如函数调用本身可作为语句) 的情况下，可能会导致混淆或意外行为。例如 func { s -> fmt.Println(s) }，如果 fmt.Println 有返回值，这个函数是返回了那些值，还是一个 void 函数？这需要非常明确的规则，并且可能依赖上下文。

4. 类型推断的复杂性与边界

虽然核心思想是“从上下文复制类型”，但当涉及到泛型时，推断会变得复杂。

Map((x) => { … }, []int{1,2,3}) ：如果 Map 是 func Map[Tin, Tout any](in []Tin, f func(Tin) Tout) []Tout，那么 Tout 如何推断？是要求显式实例化 Map[int, ReturnType]，还是尝试从 lambda 体内推断？后者将引入更复杂的双向类型推断，可能导致参数顺序影响推断结果，或在接口类型和具体类型之间产生微妙的 bug（如 typed nil 问题）。
neild 和 Merovius 指出，在很多情况下，可能需要显式提供泛型类型参数，或者接受推断的局限性。Griesemer提出的最新简化方案 (params) { statements } 明确指出其类型是从目标函数类型“复制”而来，且目标类型不能有未解析的类型参数。

5. 对 Go 语言哲学的影响

一些开发者担忧，引入过于灵活或“魔法”的语法会偏离 Go 语言简单、直接、显式优于隐式的核心哲学。他们认为现有语法虽冗长，但足够清晰，且 IDE 工具（如 gopls 的自动补全）已在一定程度上缓解了编写时的痛点。

开发者tmaxmax在其详尽的实验分析中指出，尽管标准库中单表达式函数字面量比例不高，但在其工作代码库中，这类情况更为常见，尤其是在使用泛型辅助函数如 Map、Filter 时。这表明不同代码库和使用场景下，对简洁语法的需求度可能存在差异。

最新动向：为何“可能被拒绝”？

在提案的最新comment说明中 (May 2025)，明确指出：

The Go team has decided to not proceed with adding a lightweight anonymous function syntax at this time. The complexity cost associated with the new syntax, combined with the lack of clear consensus on the syntax, makes it difficult to justify moving forward. Therefore, this proposal is likely declined for now. The issue will remain open for future consideration, but the Go team does not intend to pursue this proposal for now.

这一立场由 Robert Griesemer 在上述AI 总结中进一步确认。核心原因可以归纳为：

缺乏明确共识： 尽管讨论热烈，但社区和核心团队均未就一个理想的、被广泛接受的语法方案达成一致。各种方案都有其支持者和反对者，以及各自的优缺点和潜在问题。
复杂性成本： 任何新语法都会增加语言的复杂性（学习、实现、工具链维护、文档等）。在收益不明确或争议较大的情况下，Go 团队倾向于保守。
潜在的微妙问题与可读性担忧： 正如讨论中浮现的各种边界情况（如类型推断与泛型的交互、隐式返回的歧义、私有类型访问限制等），引入新语法需要非常谨慎。Ian Lance Taylor 明确表达了对当前显式语法在可读性方面的肯定，并对省略类型信息可能带来的阅读障碍表示担忧。
已有工具的缓解作用： 正如一些评论者指出，IDE 的自动补全功能在一定程度上减轻了编写冗长函数字面量的痛苦。

Robert Griesemer进一步总结，将备选方案缩小到 (params) { statements }, (params) { statements }, 和 (params) -> { statements } (或 =>)，并指出即使是这些方案，也各有其不完美之处。他强调了在没有明确压倒性优势方案和社区强烈共识的情况下，贸然推进的风险。

影响与未来展望

尽管 #21498 提案目前大概率会被搁置，但它所反映的开发者对于减少样板代码、提升特定场景下编码效率的诉求是真实存在的。

对迭代器和泛型库的影响： 如果提案最终未被采纳，那么严重依赖回调函数的泛型库（如设想中的 xiter 或其他函数式集合库）在使用上将保持当前的冗余度。这可能会在一定程度上抑制纯函数式风格在 Go 中的发展，或者促使开发者寻求其他模式（例如，手写循环或构建更专门的辅助函数）。有开发者认为缺乏简洁的 lambda 语法是阻碍 Go 社区充分实验函数式特性（尤其是迭代器组合）的先决条件之一。
社区的持续探索： 提案的开放状态意味着未来仍有讨论空间。如果 Go 语言在其他方面（如类型系统、元编程能力）发生演进，或者社区就某一特定语法方向形成更强共识，提案可能会被重新激活。tmaxmax 建议将讨论重心从无休止的语法细节转向更根本的动机和语义问题。
工具的进步： IDE 和代码生成工具可能会继续发展，以进一步缓解手动编写完整函数字面量的繁琐。
开发者习惯： Go 开发者将继续在现有语法框架内寻求平衡。对于高度重复的匿名函数模式，可能会更多地采用具名辅助函数或方法来封装。正如 adonovan 的实验所示，某些特定场景（如单 return 语句）可能更容易找到局部优化方案。

小结

Go 语言轻量级匿名函数语法的提案 #21498，是一场关于语言简洁性、可读性、一致性与演进方向的深刻大讨论。它暴露出在追求更现代编程范式便利性的同时，维护 Go 语言核心设计哲学的内在张力。虽然目前看来，由于缺乏明确共识和对复杂性的审慎态度，引入一种全新的、被广泛接受的简洁匿名函数语法道阻且长，但这场长达七年的讨论本身，已经为 Go 社区积累了宝贵的思考、实验数据和经验。未来，无论此提案走向何方，对代码清晰度和开发者体验的追求都将持续驱动 Go 语言的演进。Go 团队将持续观察语言的使用和社区的需求，在合适的时机可能会重新审视此类提案。

在 Go 语言的演进过程中，每一个提案的讨论都凝聚了社区的智慧和对这门语言深沉的热爱。轻量级匿名函数语法的提案，历经七年风雨，虽然目前官方倾向于搁置，但这扇门并未完全关闭。

对于 Go 开发者来说，这场旷日持久的讨论留下了哪些值得我们深思的问题？

你认为在当前 Go 的语法体系下，匿名函数的冗余是亟待解决的痛点吗？或者你认为现有的显式声明更符合 Go 的哲学？
在可读性、简洁性和语言复杂性之间，你认为 Go 应该如何权衡？
如果未来 Go 语言采纳某种形式的轻量级匿名函数，你最期待哪种语法特性（例如，类型推断、隐式返回、特定符号）？
你是否在自己的项目中因为匿名函数的冗余而选择过其他编码模式？欢迎分享你的经验和看法。

我期待在评论区看到你的真知灼见，共同探讨 Go 语言的现在与未来！

img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

从Go路由选择看“标准库优先”：何时坚守？何时拓展？

五月 14, 2025
2 条评论

本文永久链接 – https://tonybai.com/2025/05/14/which-go-router-should-you-use

大家好，我是 Tony Bai。

最近，知名 Go 博主 Alex Edwards 更新了他那篇广受欢迎的文章——“Which Go router should I use?”，特别提到了 Go 1.22 版本对标准库 http.ServeMux 的显著增强。这篇文章再次引发了我们对 Go Web 开发中一个经典问题的思考：在选择路由库时，我们应该坚守标准库，还是拥抱功能更丰富的第三方库？

这个问题，其实并不仅仅关乎路由选择，它更触及了 Go 开发哲学中一个核心原则——“标准库优先” (Standard Library First)。今天，我们就以 Go 路由选择为切入点，聊聊这个原则，以及在实践中我们该如何权衡“坚守”与“拓展”。

“标准库优先”的魅力何在？

Alex Edwards 在他的文章中旗帜鲜明地提出：“Use the standard library if you can”（如果可以，就用标准库）。这并非空穴来风，而是深深植根于 Go 语言的设计哲学和社区实践。为什么“标准库优先”如此有吸引力？

简洁性与零依赖：最直接的好处就是减少了项目的外部依赖。正如我们在之前讨论Rust 依赖管理时所看到的，过多的依赖会增加项目的复杂性、构建体积和潜在的安全风险。使用标准库，意味着你的 go.mod 文件更干净，项目更轻盈。
稳定性与兼容性：Go 语言以其著名的“Go 1 兼容性承诺”著称。标准库作为 Go 的核心组成部分，其 API 稳定性和向后兼容性得到了最高级别的保障。这意味着你可以更放心地升级 Go 版本，而不必担心标准库功能发生破坏性变更。
社区熟悉度与维护性：http.ServeMux 是每个 Gopher 都或多或少接触过的。团队成员对其有共同的认知基础，降低了学习成本和沟通成本。同时，标准库由 Go核心团队维护，其质量和响应速度通常更有保障，这对于应用的长期维护至关重要。
性能保障：虽然基准测试中某些第三方路由可能在特定场景下略胜一筹，但标准库的性能通常已经“足够好”，并且在持续优化。正如 Alex 所说，除非性能分析明确指出路由是瓶颈，否则不应过分追求极致性能而牺牲其他优势。
安全性：标准库经过了广泛的审查和实战检验，相对而言，其安全漏洞的风险更低。引入的第三方依赖越少，潜在的攻击面也就越小。

以 Go 1.22+ 的 http.ServeMux 为例，它引入了方法匹配、主机匹配、路径通配符等一系列强大的路由增强功能。这些增强使得标准库路由在很多常见场景下已经能够满足需求，进一步强化了“标准库优先”的底气。

何时坚守标准库 http.ServeMux？

在 Go 1.22 及更高版本中，http.ServeMux 的能力得到了显著提升。以下是一些典型的增强功能示例，它们展示了标准库路由的灵活性和强大性，也表明了在哪些场景下坚守标准库是理想的选择：

中小型 Web 应用或 API 服务：对于大多数标准的 CRUD 操作、简单的业务逻辑，增强后的 http.ServeMux 完全够用。
追求极致简洁和最小依赖的项目：如果项目的核心诉求是轻量、易维护，且对路由功能没有特别复杂的要求。
团队成员对 Go 标准库有良好掌握：可以充分利用团队的现有知识，快速开发和迭代。
内部工具或原型开发：快速搭建，无需引入额外学习成本。

让我们通过一个整合了多种新特性的示例来看看 Go 1.22+ http.ServeMux 的强大：

package main

import (
    "fmt"
    "net/http"
)

func main() {
    mux := http.NewServeMux()

    // 1. 方法匹配 (Method Matching)
    mux.HandleFunc("GET /api/users", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "获取用户列表 (GET)")
    })
    mux.HandleFunc("POST /api/users", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "创建新用户 (POST)")
    })

    // 2. 主机匹配 (Host Matching)
    mux.HandleFunc("api.example.com/data", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "来自 api.example.com 的数据服务")
    })
    mux.HandleFunc("www.example.com/data", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "来自 www.example.com 的数据展示")
    })

    // 3. 路径通配符 (Path Wildcards)
    // 单段通配符
    mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
        id := r.PathValue("id")
        fmt.Fprintf(w, "用户信息 (GET), 用户ID: %s", id)
    })
    // 多段通配符
    mux.HandleFunc("/files/{filepath...}", func(w http.ResponseWriter, r *http.Request) {
        path := r.PathValue("filepath")
        fmt.Fprintf(w, "文件路径: %s", path)
    })

    // 4. 结束匹配符 (End Matcher) 与优先级
    // 精确匹配根路径
    mux.HandleFunc("/{$}", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "精确匹配根路径")
    })
    // 匹配 /admin 结尾
    mux.HandleFunc("/admin/{$}", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "精确匹配 /admin 路径")
    })
    // 匹配所有 /admin 开头的路径 (注意尾部斜杠，优先级低于精确匹配)
    mux.HandleFunc("/admin/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "匹配所有 /admin/ 开头的路径")
    })

    // 5. 优先级规则：更具体的模式优先
    mux.HandleFunc("/assets/images/thumbnails/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "缩略图资源")
    })
    mux.HandleFunc("/assets/images/", func(w http.ResponseWriter, r *http.Request) { // 更一般的模式
        fmt.Fprintf(w, "所有图片资源")
    })

    fmt.Println("Server is listening on :8080...")
    http.ListenAndServe(":8080", mux)
}

你可以使用 curl 来测试上述路由，这里也附上了测试结果：

# 方法匹配
$curl -X GET http://localhost:8080/api/users
获取用户列表 (GET)                                                                                                      

$curl -X POST http://localhost:8080/api/users
创建新用户 (POST)

$curl -X PUT http://localhost:8080/api/users
Method Not Allowed

# 主机匹配 (需要修改 /etc/hosts 或使用 -H 指定 Host)
# 假设已将 api.example.com 和 www.example.com 指向 127.0.0.1
# curl http://api.example.com:8080/data
# curl http://www.example.com:8080/data
# 或者使用 -H

$curl -H "Host: api.example.com" http://localhost:8080/data
来自 api.example.com 的数据服务

$curl -H "Host: www.example.com" http://localhost:8080/data
来自 www.example.com 的数据展示

# 路径通配符

$curl http://localhost:8080/users/123
用户信息 (GET), 用户ID: 123%

$curl http://localhost:8080/files/archive/2025/report.zip
文件路径: archive/2025/report.zip

# 结束匹配符与优先级

$curl http://localhost:8080/
精确匹配根路径

$curl http://localhost:8080/admin/
精确匹配 /admin 路径

$curl http://localhost:8080/admin/settings
匹配所有 /admin/ 开头的路径

# 优先级规则
$curl http://localhost:8080/assets/images/thumbnails/cat.jpg
缩略图资源

$curl http://localhost:8080/assets/images/dog.jpg
所有图片资源

这些示例清晰地展示了 http.ServeMux 在 Go 1.22+ 版本中的强大能力。Alex Edwards 也提到 http.ServeMux 的一个聪明之处在于其处理重叠路由的逻辑——“最精确匹配的路由胜出”（例如 /post/edit 会优先于 /post/{id}）。这种可预测性也让标准库路由在设计上显得更加稳健。

简单来说，如果标准库的功能已经能满足你 80% 的需求，且剩余 20% 可以通过简单的封装或组合模式解决，那么坚守标准库通常是明智的。

何时需要拓展，拥抱第三方路由？

当然，“标准库优先”并非一成不变的教条。当标准库的功能确实无法满足项目需求，或者引入第三方库能显著提升开发效率和代码表现力时，我们就需要考虑“拓展”。

Alex Edwards 的文章也清晰地列出了 http.ServeMux（即使是增强后）与某些第三方库相比仍存在的差距，这些差距往往就是我们选择拓展的理由：

更复杂的路径参数与匹配规则：
- 子段通配符 (Subsegment wildcards)：如 chi 支持的 /articles/{month}-{year}-{day}/{id}。标准库的 {NAME…} 是捕获剩余所有路径段，而非段内复杂模式。
- 正则表达式通配符：如 gorilla/mux, chi, flow 支持的 /movies/{[a-z-]+}。标准库的通配符不直接支持正则表达式。
高级中间件管理：
- 路由组 (Middleware groups)：如 chi 和 flow 提供的，可以为一组路由批量应用中间件，这对于组织大型应用非常有用。虽然 http.ServeMux 也可以通过封装实现类似效果（Alex 也写过相关文章），但第三方库通常提供了更便捷的内建支持。
更细致的 HTTP 行为控制：
- 自定义 404/405 响应：虽然 http.ServeMux 可以通过“捕获所有”路由实现自定义 404，但这可能会影响自动的 405 响应。httprouter, chi, gorilla/mux, flow 等库对此有更好的处理，并能正确设置 Allow 头部。
- 自动处理 OPTIONS 请求：httprouter 和 flow 可以自动为 OPTIONS 请求发送正确的响应。
特定匹配需求：
- 基于请求头 (Header matching) 或 自定义匹配规则 (Custom matching rules)：gorilla/mux 在这方面表现突出，允许根据请求头（如 Authorization, Content-Type）或 IP 地址等进行路由。
其他便利功能：
- 路由反转 (Route reversing)：gorilla/mux 支持类似 Django, Rails 中的路由命名和反向生成 URL。
- 子路由 (Subrouters)：chi 和 gorilla/mux 允许创建子路由，更好地组织复杂应用的路由结构。

选择拓展的时机，关键在于评估“收益与成本”。 如果引入第三方库能让你用更少的代码、更清晰的逻辑实现复杂功能，或者能显著改善开发体验，并且团队愿意承担学习和维护这个新依赖的成本，那么拓展就是合理的。

决策的智慧：在坚守与拓展之间

那么，如何做出明智的决策呢？

清晰定义需求：在动手之前，充分理解你的应用对路由的具体需求是什么。不要为了“可能需要”的功能而过早引入复杂性。
从标准库开始：正如 Alex 建议的，总是先尝试用 http.ServeMux。只有当它确实无法满足需求时，再去评估第三方库。
小步快跑，按需引入：如果标准库满足了大部分需求，只有一小部分特殊路由需要高级功能，可以考虑混合使用，或者仅为那部分功能寻找轻量级解决方案，而不是全盘替换。
评估第三方库的成熟度与社区支持：选择那些经过良好测试、积极维护、文档齐全且社区活跃的第三方库。Alex 文章中提到的筛选标准（如是否包含 go.mod 文件）可以作为参考。
考虑团队技能与偏好：团队成员对特定库的熟悉程度也是一个重要因素。