尧图网站建设 
Mojo v0.4.0 特性详解默认参数、文件 I/O 与语言可用性全面升级【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo本指南基于当前仓库中 Mojo v0.4.0 官方发布说明发布于 2023-10-05系统梳理该版本带来的核心语言新特性、标准库变更与 Bug 修复。v0.4.0 是 Mojo 语言早期演进中的关键一版它为函数与结构体引入默认参数值补齐了基础文件 I/O 能力并大幅改善了 Python 互操作与错误处理体验。读完本文你将掌握默认参数的完整语法与优先级规则、open/with文件操作的正确写法以及 REPL 补全、显式导入等使用细节并能对照当前仓库的标准库源码理解这些能力的底层实现。版本概览v0.4.0 带来了什么v0.4.0 是 Mojo 语言发展早期阶段的重要里程碑其更新可归纳为三大方向新特性New默认参数值、file模块文件 I/O、__enter__免__exit__的上下文管理器、pathlib初版、memory.unsafe的bitcast函数、参数化类型参数直接访问、REPL 代码补全、Python 错误消息透传、动态错误消息。变更Changedparallelize函数简化、REPL/Jupyter 不再隐式暴露Python/PythonObject/Pointer、__mlir_op属性语法对齐 Python 关键字传参、Error对象可直接打印。修复Fixed修复解析器崩溃、整数构造函数、错误消息、重载决议等 13 项问题。以下逐一展开并结合仓库源码如 file.mojo、memory 模块、pathlib给出可验证的实现细节。新特性语言能力与标准库双线增强1. 默认参数值函数、推断优先级与结构体v0.4.0 为 Mojo 引入了默认参数值default parameter values能力。此前参数化函数与结构体必须显式传入所有参数现在可以在参数列表中直接给出缺省值fn foo[a: Int 3, msg: StringLiteral woof](): print(msg, a) fn main(): foo() # prints woof 3 foo[5]() # prints woof 5 foo[7, meow]() # prints meow 7注意这里的默认值作用于参数参数化编译期常量语法上是[参数名: 类型 默认值]与普通函数参数的默认值写法一致但语义属于编译期参数化体系。推断参数值优先于默认值这是该特性最微妙的规则当调用点能够从实参类型推断出参数值时编译器以推断结果为准默认值仅在无法推断时兜底value struct Bar[v: Int]: pass fn fooa: Int 42, msg: StringLiteral quack: print(msg, a) fn main(): foo(Bar[9]()) # prints quack 9上例中Bar[9]携带参数v 9函数签名foo(bar: Bar[a])通过类型匹配把a推断为9因此尽管a声明了默认值42实际打印的是9而非42。结构体同样支持默认参数value struct DefaultParams[msg: StringLiteral woof]: alias message msg fn main(): print(DefaultParams[]().message) # prints woof print(DefaultParams[meow]().message) # prints meowDefaultParams[]使用空参数列表显式触发默认值输出woof传入meow后结构体的alias message绑定到新值。这一特性为后续 Mojo 泛型 API 设计如大量带默认origin、lifetime参数的库接口打下了基础。2. 文件 I/O新的file模块v0.4.0 新增的file模块提供了基础文件读写能力。在当时的版本中open是内建函数无需显式 import 即可使用var f open(my_file.txt, r) print(f.read()) f.close()或使用with语句在离开作用域时自动关闭文件with open(my_file.txt, r) as f: print(f.read())当前仓库中的实现印证在 Mojo/stdlib/std/io/file.mojo 中模块文档开头就给出了与 v0.4.0 发布说明完全一致的两种用法示例file.mojo L13-L31。从源码可以进一步看清底层设计_open_filefile.mojo L79负责解析模式字符串并映射为 POSIX open flagsr→O_RDONLY | O_CLOEXECw→O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXECrw→O_RDWR | O_CREAT | O_CLOEXECa→O_WRONLY | O_CREAT | O_APPEND | O_CLOEXEC非法模式会抛出Error。打开时通过external_call[open, ...]直接调用系统调用file.mojo L135文件描述符为 -1 时结合get_errno()生成带系统错误码的中文友好错误。写模式w/rw/a下会自动创建缺失的父目录file.mojo L117-L129。FileHandlefile.mojo L151封装底层 fdread(size: Int -1)默认读到 EOFfile.mojo L200支持seek定位后分片读取close()在__deinit__中兜底调用保证资源释放。从实现演进看v0.4.0 的 basic file I/O 如今已成长为带读写缓冲、目录自动创建、跨平台 flag 映射platform_map区分 linux/macos 的O_CREAT等常量见 file.mojo L58-L72的完整模块。3. 上下文管理器允许只有__enter__而没有__exit__v0.4.0 放宽了with语句对上下文管理器协议的要求类型可以只实现__enter__而不实现__exit__。典型用法是消费自身并返回自身的惯用法# 这个上下文管理器消费自身并把自身作为值返回。 fn __enter__(owned self) - Self: return self^发布说明特别解释了原因当__enter__以owned self消费了上下文管理器对象后Mojo无法再调用一个 noop 的__exit__因为对象已被移动走。这种模式适用于文件描述符等传统上配合with使用的类型——即使 Mojo 的保证尽早析构guaranteed early destruction语义并不强制要求使用with该语法仍然为习惯 Python 写法的开发者提供了熟悉的选择。这体现了 Mojo 所有权模型move 语义与 Python 上下文管理器协议的融合借用 Rust 的 RAII 思想的同时保留 Python 式的语法糖。4.pathlib初版落地v0.4.0 在 Mojo 中实现了非常基础版本的pathlib。发布说明明确指出该模块会在后续数个版本中持续改进最终与 Python 的pathlib达到功能对等functional parity。当前仓库中该模块已演进为 Mojo/stdlib/std/pathlib/path.mojo包含Path/PurePath等类型定义。这意味着路径拼接、父目录获取、文件存在性判断等日常操作可以在纯 Mojo 代码中完成无需退回字符串手工处理。5.memory.unsafe新增bitcast指针与标量的底层互转memory.unsafe模块新增了bitcast函数这是一种底层操作用于在指针与标量之间进行按位转换bitcasting。它的典型场景包括将整数地址直接转为指针、在指针与Int/UInt之间搬运、实现零拷贝的类型重新解释。从当前仓库 Mojo/stdlib/std/memory/init.mojo L59 可以看到该符号的导出from .unsafe import bitcast, pack_bits同时指针类型普遍提供unsafe_bitcast[T]()方法如 memory.mojo L151-L155 中memcmp实现把字节指针按UInt32视图批量比较正是 bitcast 提速内存操作的实例。需要提醒的是bitcast属于unsafe命名空间调用者必须自行保证目标类型的内存布局与对齐约束误用会引入未定义行为。6. 参数化类型的参数可直接作为属性访问v0.4.0 允许把参数化类型parametric type的输入参数直接作为类型或变量的属性来访问value struct Thing[param: Int]: pass fn main(): print(Thing[2].param) # prints 2 let x Thing[9]() print(x.param) # prints 9更进一步值上的输入参数甚至可以在参数编译期上下文中使用fn foo[value: Int](): print(value) let y Thing[12]() alias constant y.param 4 foo[constant]() # prints 16y.param在编译期可知等于12因此可以被提升为alias编译期常量并作为参数传给另一个参数化函数。这一特性让携带参数的实体类型真正具备了类型级元数据反射能力是后续 Mojo 张量形状、静态维度推断等功能的重要基石。7. REPL 代码补全Mojo REPL 新增代码补全支持输入过程中按Tab即可查询候选补全结果。这显著改善了交互式探索 Mojo API 的体验让开发者可以在不离开终端的情况下快速发现模块成员与函数签名。当前仓库 tools/mojo-lsp-server 与 utils/jupyter-mojo 等工具链的存在说明补全能力背后是语言服务器协议LSP基础设施的持续建设。8. Python 错误消息在 Mojo 中透传v0.4.0 之前Mojo 调用 Python 抛出的异常只会显示笼统信息现在 Mojo 会把 Python 的原始错误消息暴露出来fn main(): try: let my_module Python.import_module(my_uninstalled_module) except e: print(e)上面代码应打印No module named my_uninstalled_module——这正是 CPython 在 import 失败时的标准消息。该能力的实现依托PythonObject异常链的提取与格式化见当前仓库 Mojo/stdlib/std/python/python_object.mojo 相关异常处理逻辑。9. 错误消息支持动态内容此前Error的文本基本是静态字符串v0.4.0 起错误可以携带运行时动态构造的消息fn foo(x: String) raises: raise Error(Failed on: x) fn main(): try: foo(Hello) except e: print(e)上面代码应打印Failed on: Hello。字符串拼接结果被完整保留在错误对象中这意味着库作者可以为调用者提供包含具体变量值、上下文路径的诊断信息而不是干巴巴的固定文案。变更API 与语法的兼容性调整1.parallelize函数简化parallelize函数得到改进与简化通过缓存 Mojo 并行运行时parallel runtime省去部分重复初始化开销。调用方写法不变但并行任务分发更轻量。这与仓库 AsyncRT 运行时中线程池/工作队列的实现方向一致——并行基础设施的复用与缓存是降低任务启动延迟的关键。2. REPL 与 Jupyter 不再隐式暴露 Python 符号v0.4.0 起REPL 和 Jupyter 环境不再自动注入Python、PythonObject、Pointer必须显式导入from python import Python from python.object import PythonObject from memory.unsafe import Pointer这是一次显式优于隐式的 API 清理减少命名冲突、让代码的可移植性更强同样的 import 语句在脚本与笔记本中都成立。注意Pointer位于memory.unsafe与当前仓库 memory/init.mojo 的导出结构一致。3.__mlir_op属性语法对齐 Python 关键字参数使用__mlir_op前缀指定 MLIR 操作属性时语法从冒号改为等号与 Python 关键字参数风格一致# 旧语法现在会失败。 __mlir_op.index.bool.constant[value : __mlir_attr.false]() # 新语法。 __mlir_op.index.bool.constant[value__mlir_attr.false]()这是面向编译器内建操作如index.bool.constant的底层语法调整只影响直接编写 MLIR 方言内联操作的场景普通 Mojo 代码不受影响。4.Error对象可直接打印Error现在可以直接传给print输出其message()方法被移除except e: print(e) # 新方式直接打印错误文本配合上文动态错误消息与Python 错误透传except e: print(e)成为 v0.4.0 之后最简洁统一的错误查看范式。修复清单13 项稳定性改进v0.4.0 修复了以下问题编号取自当时 Modular 的 issue 跟踪编号问题描述类别#794使用in运算符时解析器崩溃解析器#936Int构造函数现在接受其他Int实例标准库#921对没有main函数的模块运行mojo时给出更清晰的错误消息编译器驱动#556UInt64现在能正确打印标准库#804传递不支持类型的可变参数时改为报错而非崩溃编译器#833给模块值赋值时解析器崩溃解析器#752调用 async def 时解析器崩溃解析器#711重载决议优先选择实例方法而非静态方法匹配质量相同时且修复静态方法首参为Self类型时的崩溃类型系统#859修正rebind内建函数的误导性错误消息与文档编译器#753直接使用 LLVM 方言产生奇怪错误编译器#926返回类型为StringRef的函数抛错时不再错误地返回该错误的字符串值编译器#536报告更丰富的 Python 异常信息Python 互操作其中 #711实例方法优先于静态方法与 #536Python 异常信息分别呼应了上文的重载决议改进与错误透传特性属于同一批错误处理与类型系统打磨工作的组成部分。小结v0.4.0 的历史定位综合来看v0.4.0 完成了三件事补齐语言基础能力默认参数、参数属性访问、打通系统编程走廊文件 I/O、pathlib、bitcast、改善开发者体验REPL 补全、错误透传、异常诊断。对照当前仓库v0.4.0 播下的种子——file模块、memory.unsafe.bitcast、pathlib——如今已长成 Mojo/stdlib/std/io/file.mojo、Mojo/stdlib/std/memory、Mojo/stdlib/std/pathlib/path.mojo 等完整实现这也从侧面印证了该版本 API 设计方向的正确性。对于希望理解 Mojo 语言演进脉络、或需要编写可移植 Mojo 代码的开发者v0.4.0 的这些约定至今仍具参考价值。【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mojo v0.4.0 特性详解：默认参数、文件 I/O 与语言可用性全面升级
Mojo v0.4.0 特性详解默认参数、文件 I/O 与语言可用性全面升级【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo本指南基于当前仓库中 Mojo v0.4.0 官方发布说明发布于 2023-10-05系统梳理该版本带来的核心语言新特性、标准库变更与 Bug 修复。v0.4.0 是 Mojo 语言早期演进中的关键一版它为函数与结构体引入默认参数值补齐了基础文件 I/O 能力并大幅改善了 Python 互操作与错误处理体验。读完本文你将掌握默认参数的完整语法与优先级规则、open/with文件操作的正确写法以及 REPL 补全、显式导入等使用细节并能对照当前仓库的标准库源码理解这些能力的底层实现。版本概览v0.4.0 带来了什么v0.4.0 是 Mojo 语言发展早期阶段的重要里程碑其更新可归纳为三大方向新特性New默认参数值、file模块文件 I/O、__enter__免__exit__的上下文管理器、pathlib初版、memory.unsafe的bitcast函数、参数化类型参数直接访问、REPL 代码补全、Python 错误消息透传、动态错误消息。变更Changedparallelize函数简化、REPL/Jupyter 不再隐式暴露Python/PythonObject/Pointer、__mlir_op属性语法对齐 Python 关键字传参、Error对象可直接打印。修复Fixed修复解析器崩溃、整数构造函数、错误消息、重载决议等 13 项问题。以下逐一展开并结合仓库源码如 file.mojo、memory 模块、pathlib给出可验证的实现细节。新特性语言能力与标准库双线增强1. 默认参数值函数、推断优先级与结构体v0.4.0 为 Mojo 引入了默认参数值default parameter values能力。此前参数化函数与结构体必须显式传入所有参数现在可以在参数列表中直接给出缺省值fn foo[a: Int 3, msg: StringLiteral woof](): print(msg, a) fn main(): foo() # prints woof 3 foo[5]() # prints woof 5 foo[7, meow]() # prints meow 7注意这里的默认值作用于参数参数化编译期常量语法上是[参数名: 类型 默认值]与普通函数参数的默认值写法一致但语义属于编译期参数化体系。推断参数值优先于默认值这是该特性最微妙的规则当调用点能够从实参类型推断出参数值时编译器以推断结果为准默认值仅在无法推断时兜底value struct Bar[v: Int]: pass fn fooa: Int 42, msg: StringLiteral quack: print(msg, a) fn main(): foo(Bar[9]()) # prints quack 9上例中Bar[9]携带参数v 9函数签名foo(bar: Bar[a])通过类型匹配把a推断为9因此尽管a声明了默认值42实际打印的是9而非42。结构体同样支持默认参数value struct DefaultParams[msg: StringLiteral woof]: alias message msg fn main(): print(DefaultParams[]().message) # prints woof print(DefaultParams[meow]().message) # prints meowDefaultParams[]使用空参数列表显式触发默认值输出woof传入meow后结构体的alias message绑定到新值。这一特性为后续 Mojo 泛型 API 设计如大量带默认origin、lifetime参数的库接口打下了基础。2. 文件 I/O新的file模块v0.4.0 新增的file模块提供了基础文件读写能力。在当时的版本中open是内建函数无需显式 import 即可使用var f open(my_file.txt, r) print(f.read()) f.close()或使用with语句在离开作用域时自动关闭文件with open(my_file.txt, r) as f: print(f.read())当前仓库中的实现印证在 Mojo/stdlib/std/io/file.mojo 中模块文档开头就给出了与 v0.4.0 发布说明完全一致的两种用法示例file.mojo L13-L31。从源码可以进一步看清底层设计_open_filefile.mojo L79负责解析模式字符串并映射为 POSIX open flagsr→O_RDONLY | O_CLOEXECw→O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXECrw→O_RDWR | O_CREAT | O_CLOEXECa→O_WRONLY | O_CREAT | O_APPEND | O_CLOEXEC非法模式会抛出Error。打开时通过external_call[open, ...]直接调用系统调用file.mojo L135文件描述符为 -1 时结合get_errno()生成带系统错误码的中文友好错误。写模式w/rw/a下会自动创建缺失的父目录file.mojo L117-L129。FileHandlefile.mojo L151封装底层 fdread(size: Int -1)默认读到 EOFfile.mojo L200支持seek定位后分片读取close()在__deinit__中兜底调用保证资源释放。从实现演进看v0.4.0 的 basic file I/O 如今已成长为带读写缓冲、目录自动创建、跨平台 flag 映射platform_map区分 linux/macos 的O_CREAT等常量见 file.mojo L58-L72的完整模块。3. 上下文管理器允许只有__enter__而没有__exit__v0.4.0 放宽了with语句对上下文管理器协议的要求类型可以只实现__enter__而不实现__exit__。典型用法是消费自身并返回自身的惯用法# 这个上下文管理器消费自身并把自身作为值返回。 fn __enter__(owned self) - Self: return self^发布说明特别解释了原因当__enter__以owned self消费了上下文管理器对象后Mojo无法再调用一个 noop 的__exit__因为对象已被移动走。这种模式适用于文件描述符等传统上配合with使用的类型——即使 Mojo 的保证尽早析构guaranteed early destruction语义并不强制要求使用with该语法仍然为习惯 Python 写法的开发者提供了熟悉的选择。这体现了 Mojo 所有权模型move 语义与 Python 上下文管理器协议的融合借用 Rust 的 RAII 思想的同时保留 Python 式的语法糖。4.pathlib初版落地v0.4.0 在 Mojo 中实现了非常基础版本的pathlib。发布说明明确指出该模块会在后续数个版本中持续改进最终与 Python 的pathlib达到功能对等functional parity。当前仓库中该模块已演进为 Mojo/stdlib/std/pathlib/path.mojo包含Path/PurePath等类型定义。这意味着路径拼接、父目录获取、文件存在性判断等日常操作可以在纯 Mojo 代码中完成无需退回字符串手工处理。5.memory.unsafe新增bitcast指针与标量的底层互转memory.unsafe模块新增了bitcast函数这是一种底层操作用于在指针与标量之间进行按位转换bitcasting。它的典型场景包括将整数地址直接转为指针、在指针与Int/UInt之间搬运、实现零拷贝的类型重新解释。从当前仓库 Mojo/stdlib/std/memory/init.mojo L59 可以看到该符号的导出from .unsafe import bitcast, pack_bits同时指针类型普遍提供unsafe_bitcast[T]()方法如 memory.mojo L151-L155 中memcmp实现把字节指针按UInt32视图批量比较正是 bitcast 提速内存操作的实例。需要提醒的是bitcast属于unsafe命名空间调用者必须自行保证目标类型的内存布局与对齐约束误用会引入未定义行为。6. 参数化类型的参数可直接作为属性访问v0.4.0 允许把参数化类型parametric type的输入参数直接作为类型或变量的属性来访问value struct Thing[param: Int]: pass fn main(): print(Thing[2].param) # prints 2 let x Thing[9]() print(x.param) # prints 9更进一步值上的输入参数甚至可以在参数编译期上下文中使用fn foo[value: Int](): print(value) let y Thing[12]() alias constant y.param 4 foo[constant]() # prints 16y.param在编译期可知等于12因此可以被提升为alias编译期常量并作为参数传给另一个参数化函数。这一特性让携带参数的实体类型真正具备了类型级元数据反射能力是后续 Mojo 张量形状、静态维度推断等功能的重要基石。7. REPL 代码补全Mojo REPL 新增代码补全支持输入过程中按Tab即可查询候选补全结果。这显著改善了交互式探索 Mojo API 的体验让开发者可以在不离开终端的情况下快速发现模块成员与函数签名。当前仓库 tools/mojo-lsp-server 与 utils/jupyter-mojo 等工具链的存在说明补全能力背后是语言服务器协议LSP基础设施的持续建设。8. Python 错误消息在 Mojo 中透传v0.4.0 之前Mojo 调用 Python 抛出的异常只会显示笼统信息现在 Mojo 会把 Python 的原始错误消息暴露出来fn main(): try: let my_module Python.import_module(my_uninstalled_module) except e: print(e)上面代码应打印No module named my_uninstalled_module——这正是 CPython 在 import 失败时的标准消息。该能力的实现依托PythonObject异常链的提取与格式化见当前仓库 Mojo/stdlib/std/python/python_object.mojo 相关异常处理逻辑。9. 错误消息支持动态内容此前Error的文本基本是静态字符串v0.4.0 起错误可以携带运行时动态构造的消息fn foo(x: String) raises: raise Error(Failed on: x) fn main(): try: foo(Hello) except e: print(e)上面代码应打印Failed on: Hello。字符串拼接结果被完整保留在错误对象中这意味着库作者可以为调用者提供包含具体变量值、上下文路径的诊断信息而不是干巴巴的固定文案。变更API 与语法的兼容性调整1.parallelize函数简化parallelize函数得到改进与简化通过缓存 Mojo 并行运行时parallel runtime省去部分重复初始化开销。调用方写法不变但并行任务分发更轻量。这与仓库 AsyncRT 运行时中线程池/工作队列的实现方向一致——并行基础设施的复用与缓存是降低任务启动延迟的关键。2. REPL 与 Jupyter 不再隐式暴露 Python 符号v0.4.0 起REPL 和 Jupyter 环境不再自动注入Python、PythonObject、Pointer必须显式导入from python import Python from python.object import PythonObject from memory.unsafe import Pointer这是一次显式优于隐式的 API 清理减少命名冲突、让代码的可移植性更强同样的 import 语句在脚本与笔记本中都成立。注意Pointer位于memory.unsafe与当前仓库 memory/init.mojo 的导出结构一致。3.__mlir_op属性语法对齐 Python 关键字参数使用__mlir_op前缀指定 MLIR 操作属性时语法从冒号改为等号与 Python 关键字参数风格一致# 旧语法现在会失败。 __mlir_op.index.bool.constant[value : __mlir_attr.false]() # 新语法。 __mlir_op.index.bool.constant[value__mlir_attr.false]()这是面向编译器内建操作如index.bool.constant的底层语法调整只影响直接编写 MLIR 方言内联操作的场景普通 Mojo 代码不受影响。4.Error对象可直接打印Error现在可以直接传给print输出其message()方法被移除except e: print(e) # 新方式直接打印错误文本配合上文动态错误消息与Python 错误透传except e: print(e)成为 v0.4.0 之后最简洁统一的错误查看范式。修复清单13 项稳定性改进v0.4.0 修复了以下问题编号取自当时 Modular 的 issue 跟踪编号问题描述类别#794使用in运算符时解析器崩溃解析器#936Int构造函数现在接受其他Int实例标准库#921对没有main函数的模块运行mojo时给出更清晰的错误消息编译器驱动#556UInt64现在能正确打印标准库#804传递不支持类型的可变参数时改为报错而非崩溃编译器#833给模块值赋值时解析器崩溃解析器#752调用 async def 时解析器崩溃解析器#711重载决议优先选择实例方法而非静态方法匹配质量相同时且修复静态方法首参为Self类型时的崩溃类型系统#859修正rebind内建函数的误导性错误消息与文档编译器#753直接使用 LLVM 方言产生奇怪错误编译器#926返回类型为StringRef的函数抛错时不再错误地返回该错误的字符串值编译器#536报告更丰富的 Python 异常信息Python 互操作其中 #711实例方法优先于静态方法与 #536Python 异常信息分别呼应了上文的重载决议改进与错误透传特性属于同一批错误处理与类型系统打磨工作的组成部分。小结v0.4.0 的历史定位综合来看v0.4.0 完成了三件事补齐语言基础能力默认参数、参数属性访问、打通系统编程走廊文件 I/O、pathlib、bitcast、改善开发者体验REPL 补全、错误透传、异常诊断。对照当前仓库v0.4.0 播下的种子——file模块、memory.unsafe.bitcast、pathlib——如今已长成 Mojo/stdlib/std/io/file.mojo、Mojo/stdlib/std/memory、Mojo/stdlib/std/pathlib/path.mojo 等完整实现这也从侧面印证了该版本 API 设计方向的正确性。对于希望理解 Mojo 语言演进脉络、或需要编写可移植 Mojo 代码的开发者v0.4.0 的这些约定至今仍具参考价值。【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考