仓颉编程语言深度解析：值得学吗？

2024 年华为正式发布了仓颉编程语言（Cangjie），在开发者圈子里激起了不少讨论。有人把它看作"中国自主编程语言的里程碑"，也有人觉得不过是又一种注定小众的语言。我花了些时间研究它的语法和设计哲学，这篇文章说说我的判断。

仓颉是什么

简单说：仓颉是华为自研的静态类型编译型编程语言，面向 HarmonyOS 生态。它不基于任何现有语言（不是 Java/Kotlin 的分支，也不是 Rust 的封装），是完全从零设计的。

它的定位很明确——成为 HarmonyOS 应用开发的主力语言，逐步替代 Java 和 Kotlin。

语法概览

仓颉的语法融合了多种语言的优点。先看一段变量声明：

// 仓颉 (Cangjie)
let name: String = "Hello"
var count: Int64 = 0
let list: ArrayList<String> = ArrayList<String>()

对比 Kotlin：

val name: String = "Hello"
var count: Long = 0
val list: ArrayList<String> = ArrayList()

对比 Swift：

let name: String = "Hello"
var count: Int64 = 0
let list: [String] = []

可以看出，仓颉的 let/var 语法跟 Swift 基本一致，类型标注方式也类似。这是有意为之——降低 Swift 开发者的迁移成本，同时也吸引对 Kotlin 熟悉的 Android 开发者。

函数和闭包

// 仓颉
func add(a: Int64, b: Int64): Int64 {
    return a + b
}

// 匿名函数 / 闭包
let multiply = { (a: Int64, b: Int64) =>
    a * b
}

// 高阶函数
func operate(a: Int64, b: Int64, op: (Int64, Int64) -> Int64): Int64 {
    return op(a, b)
}

对比 Rust：

fn add(a: i64, b: i64) -> i64 {
    a + b
}

let multiply = |a: i64, b: i64| a * b;

fn operate(a: i64, b: i64, op: fn(i64, i64) -> i64) -> i64 {
    op(a, b)
}

返回类型后置、花括号块、闭包的箭头语法——这些设计明显参考了 Rust 的函数式特性。

空安全

仓颉实现了类似 Kotlin 的空安全：

// 仓颉
var name: String? = null  // 可空类型
name = "仓颉"
let length = name?.length ?? 0  // 安全调用 + 默认值

// 对比 Kotlin
var name: String? = null
name = "Kotlin"
val length = name?.length ?: 0

几乎一模一样。做过 Kotlin 开发的人对这一套不会有任何学习成本。

并发模型：Actor

这是仓颉最有特色的设计——它用 Actor 模型处理并发：

// 仓颉
actor Counter {
    var value: Int64 = 0
    
    func increment() {
        value += 1
    }
    
    func getValue(): Int64 {
        return value
    }
}

let counter = Counter()
counter.increment()
let result = counter.getValue()

Actor 保证了其内部状态的线程安全——多个 Actor 之间通过消息通信，不存在共享内存竞争的问题。这跟 Erlang/Elixir 的并发哲学一致，但仓颉的语法更接近 Swift 的 Actor。

对比 Kotlin 的协程：

// Kotlin 需要手动处理同步
class Counter {
    private var value = 0L
    
    @Synchronized
    fun increment() { value++ }
    
    @Synchronized
    fun getValue(): Long = value
}

Kotlin 的协程 + 同步锁可以解决同样的问题，但 Actor 模型更符合"设计即安全"的理念。

模式匹配

// 仓颉
func describe(x: Any): String {
    match (x) {
        case i: Int64 => "整数: ${i}"
        case s: String => "字符串: ${s}"
        case _ => "未知类型"
    }
}

对比 Rust：

fn describe(x: &dyn Any) -> String {
    match x.type_id() {
        // Rust 的模式匹配更底层，需要类型 ID 判断
    }
}

对比 Swift：

func describe(_ x: Any) -> String {
    switch x {
    case let i as Int: return "整数: \(i)"
    case let s as String: return "字符串: \(s)"
    default: return "未知类型"
    }
}

仓颉的 match 语法最像 Rust，但类型匹配的方式更接近 Swift 的 switch + as 模式。

仓颉的优势

原生 HarmonyOS 支持。 这是仓颉存在的根本原因。它不是"也能跑在 HarmonyOS 上"，而是专门为 ArkUI 框架和鸿蒙内核优化的。调用系统 API 零开销，编译产物直接运行在 HarmonyOS 的内核之上。

现代语言特性一步到位。 空安全、类型推断、模式匹配、Actor 并发——这些都是 2020 年代编程语言的标配。仓颉不用像 Java 那样花十年慢慢加特性，它一开始就全有。

中国人主导，中文社区友好。 文档是中文的，社区是中文的，遇到问题不用翻 Stack Overflow 等翻译。这对英文不好的开发者是个实在的优势。

仓颉的劣势

生态几乎为零。 这是最致命的问题。截止 2025 年中，GitHub 上仓颉的开源项目少得可怜。没有成熟的第三方库，没有 Stack Overflow 上的解决方案，你遇到的大部分问题只能靠看官方文档自己解决。对比 Flutter 的 pub.dev 上几万个包，仓颉的生态差了不止一个数量级。

被锁定在 HarmonyOS 生态。 仓颉目前只在 HarmonyOS 上能跑。如果你以后想开发 Android 应用、iOS 应用、后端服务——仓颉帮不了你。Kotlin 学了能用在后端（Spring Boot）、前端（Kotlin/JS）、移动端（Android）、甚至 iOS（KMP），仓颉只能用在鸿蒙。

不确定性大。 2025 年的 HarmonyOS 生态还不是主流。如果几年后 HarmonyOS 的市场份额没能起来，你学的仓颉技能可能就没什么用了。这是个赌注，赌 HarmonyOS 会成功。

语法还在变。 作为一门年轻语言，仓颉的语法还没有稳定。2024 年的写法可能跟 2025 年的写法不完全一样。你写的东西过半年可能需要改。

跟其他语言的定位对比

语言	定位	成熟度	生态
仓颉	HarmonyOS 主力语言	⭐	⭐
Kotlin	Android 主力 + 多平台	⭐⭐⭐⭐	⭐⭐⭐⭐
Swift	Apple 生态主力	⭐⭐⭐⭐	⭐⭐⭐
Dart/Flutter	跨平台移动端	⭐⭐⭐	⭐⭐⭐
Rust	系统级通用	⭐⭐⭐⭐	⭐⭐⭐