首页
/ Google Java Format全场景问题诊断与解决方案指南

Google Java Format全场景问题诊断与解决方案指南

2026-05-03 11:10:57作者：余洋婵Anita
google-java-format
Reformats Java source code to comply with Google Java Style.
项目地址：https://gitcode.com/gh_mirrors/goo/google-java-format

一、环境配置类问题：从启动失败到运行异常

场景引入

当你在终端输入格式化命令后，屏幕显示"找不到主类"或"UnsupportedClassVersionError"错误时，可能正遭遇环境配置类问题。这类问题通常表现为工具无法启动或启动后立即崩溃，直接阻碍开发工作流。

问题现象

  • 命令行执行java -jar google-java-format.jar无响应或报错
  • IDE插件安装后无法启用，提示"JRE配置错误"
  • 格式化过程中突然终止并显示JVM相关异常

原因分析

  1. 版本兼容性问题：Java运行时版本与工具版本不匹配，特别是在JDK 16+环境中
  2. JVM参数缺失：高版本JDK需要特定的--add-exports参数才能访问内部API
  3. 文件权限问题：JAR文件或目标文件没有足够的读写权限
  4. 环境变量配置：JAVA_HOME设置错误或未包含在系统PATH中

分级解决方案

基础解决方案：版本匹配与权限检查

📌 步骤1：确认Java版本与工具版本兼容性

# 检查Java版本
java -version

# 查看工具支持的Java版本范围
java -jar google-java-format-1.17.0-all-deps.jar --version

📌 步骤2：验证文件权限

# 检查JAR文件权限
ls -l google-java-format-1.17.0-all-deps.jar

# 添加执行权限（如需要）
chmod +x google-java-format-1.17.0-all-deps.jar

进阶解决方案：JVM参数配置

对于JDK 16及以上版本，需要添加特定参数：

方案A：命令行直接添加参数

java --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED \
     -jar google-java-format-1.17.0-all-deps.jar --replace MyClass.java

方案B：创建启动脚本封装参数

# 创建名为gjf的bash脚本
cat > gjf << 'EOF'
#!/bin/bash
java --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED \
     --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED \
     -jar /path/to/google-java-format-1.17.0-all-deps.jar "$@"
EOF

# 赋予执行权限
chmod +x gjf

# 使用脚本
./gjf --replace MyClass.java

预防措施

⚠️ 始终使用工具官方推荐的Java版本，在项目README中明确标注版本要求 ⚠️ 为团队创建统一的启动脚本或配置模板，避免重复配置 ⚠️ 在CI/CD环境中添加Java版本和环境检查步骤 ⚠️ 定期检查工具更新，关注版本兼容性变更

问题自检清单

  • [ ] Java版本是否符合工具要求（通常JDK 11+）
  • [ ] 高版本JDK是否添加了必要的--add-exports参数
  • [ ] JAR文件是否具有正确的权限
  • [ ] JAVA_HOME环境变量是否正确配置
  • [ ] 工具版本是否为最新稳定版

二、IDE集成类问题：从插件安装到自动格式化

场景引入

当你在IntelliJ IDEA中按下Ctrl+Alt+L格式化代码时，发现代码风格没有按预期变化，或者IDE提示"Google Java Format插件未启用"，这表明你遇到了IDE集成类问题。

问题现象

  • IDE中找不到Google Java Format相关设置
  • 格式化快捷键执行的是IDE默认格式化而非Google Java Format
  • 保存文件时未触发自动格式化
  • 插件安装后IDE启动报错

原因分析

  1. 插件安装不完整：市场中存在多个类似名称的插件，可能安装了非官方版本
  2. 配置未生效：已安装插件但未在IDE设置中启用
  3. 快捷键冲突：与其他插件或IDE默认快捷键冲突
  4. 版本不匹配：IDE版本与插件版本不兼容
  5. 缓存问题：IDE缓存导致插件设置未正确加载

分级解决方案

基础解决方案：插件安装与启用

📌 步骤1：安装官方插件

  • IntelliJ IDEA：在插件市场搜索"Google Java Format"并安装
  • Eclipse：通过"Help > Eclipse Marketplace"搜索并安装

📌 步骤2：启用插件

  1. 进入 File → Settings → Tools → google-java-format
  2. 勾选"Enable google-java-format"选项
  3. 点击"Apply"并重启IDE

进阶解决方案：深度配置与问题排查

方案A：配置自动格式化

  1. 进入 File → Settings → Editor → General → Editor Tabs
  2. 勾选"Save files on frame deactivation"
  3. 进入 File → Settings → Tools → google-java-format
  4. 勾选"Format on save"选项

方案B：解决快捷键冲突

  1. 进入 File → Settings → Keymap
  2. 搜索"Reformat Code"
  3. 右键点击该操作，选择"Remove Ctrl+Alt+L"
  4. 搜索"google-java-format"相关操作
  5. 为"Format with google-java-format"分配快捷键

方案C：手动触发插件修复

# 清除IDE缓存（IntelliJ示例）
rm -rf ~/.local/share/JetBrains/IntelliJIdea*/caches

# 重新安装插件

预防措施

⚠️ 在团队范围内统一IDE和插件版本 ⚠️ 将格式化配置纳入项目共享设置（如IntelliJ的Project Settings） ⚠️ 定期检查插件更新，保持与IDE版本同步 ⚠️ 避免安装多个功能类似的格式化插件

问题自检清单

  • [ ] 安装的是官方发布的Google Java Format插件
  • [ ] 插件已在IDE设置中启用
  • [ ] 已正确配置格式化快捷键
  • [ ] "Format on save"功能已启用
  • [ ] IDE重启后插件仍能正常工作

三、代码格式化类问题：从部分格式化到批量处理

场景引入

当你需要紧急提交代码却发现整个项目的格式都不符合要求，手动逐个文件处理显然不现实。或者你只想格式化修改过的部分代码，避免不必要的代码变动，这些都属于代码格式化类问题。

问题现象

  • 执行格式化命令后文件没有任何变化
  • 只需要格式化部分代码却影响了整个文件
  • 批量格式化时部分文件失败并报错
  • 格式化后的代码出现语法错误

原因分析

  1. 文件语法错误：代码中存在语法错误导致格式化失败
  2. 参数使用不当：未正确使用部分格式化参数
  3. 编码问题：文件使用非UTF-8编码导致乱码
  4. 文件权限：工具没有写入文件的权限
  5. 复杂代码结构：某些特殊语法结构可能导致格式化异常

分级解决方案

基础解决方案：基本格式化操作

📌 单个文件格式化

java -jar google-java-format-1.17.0-all-deps.jar --replace MyClass.java

📌 部分代码格式化

# 按行号格式化
java -jar google-java-format-1.17.0-all-deps.jar --lines 10:20 --replace MyClass.java

# 按字符偏移量格式化
java -jar google-java-format-1.17.0-all-deps.jar --offset 100:200 --replace MyClass.java

进阶解决方案：批量与选择性格式化

方案A：使用find命令批量处理

# 格式化当前目录及子目录下所有Java文件
find . -name "*.java" -exec java -jar google-java-format-1.17.0-all-deps.jar --replace {} \;

# 格式化最近修改的Java文件（过去24小时）
find . -name "*.java" -mtime -1 -exec java -jar google-java-format-1.17.0-all-deps.jar --replace {} \;

方案B：使用git diff筛选修改文件

# 格式化暂存区中的Java文件
git diff --cached --name-only -- '*.java' | xargs java -jar google-java-format-1.17.0-all-deps.jar --replace

# 格式化与主分支相比修改的文件
git diff main --name-only -- '*.java' | xargs java -jar google-java-format-1.17.0-all-deps.jar --replace

方案C：使用格式化差异工具

# 使用项目提供的差异格式化脚本
python scripts/google-java-format-diff.py --help

# 格式化特定提交范围内的变更
git diff -U0 HEAD~1 HEAD | python scripts/google-java-format-diff.py -p1 -i

预防措施

⚠️ 在提交代码前先进行局部格式化，避免大量无意义变更 ⚠️ 使用--dry-run参数预览格式化效果，确认无误后再执行替换 ⚠️ 对于大型项目，分模块逐步进行格式化，避免一次性修改过多文件 ⚠️ 格式化前确保代码能够通过编译，避免因语法错误导致格式化失败

问题自检清单

  • [ ] 是否使用了正确的格式化参数（--replace, --lines等）
  • [ ] 文件是否有语法错误
  • [ ] 工具是否有文件写入权限
  • [ ] 是否预览了格式化效果
  • [ ] 批量处理时是否设置了合理的过滤条件

四、构建集成类问题：从Maven配置到CI流水线

场景引入

当你在CI流水线中看到"代码格式检查失败"的红色警告，或者团队成员提交了未格式化的代码导致构建失败，这说明你需要解决构建集成类问题，将格式化检查融入开发流程。

问题现象

  • Maven/Gradle构建过程中未执行格式化检查
  • CI流水线中格式化检查耗时过长
  • 本地格式化与CI检查结果不一致
  • 构建工具与Google Java Format版本冲突

原因分析

  1. 插件配置错误：构建工具插件未正确配置或版本不兼容
  2. 执行时机不当：格式化检查未在正确的构建阶段执行
  3. 环境差异：本地环境与CI环境的工具版本不一致
  4. 缓存问题：CI环境中的依赖缓存导致工具版本未更新
  5. 资源限制：CI环境资源不足导致格式化检查超时

分级解决方案

基础解决方案：Maven集成

📌 Maven插件配置

<plugin>
    <groupId>com.google.googlejavaformat</groupId>
    <artifactId>google-java-format-maven-plugin</artifactId>
    <version>1.17.0</version>
    <executions>
        <execution>
            <goals>
                <goal>validate</goal>
            </goals>
        </execution>
    </executions>
</plugin>

📌 执行格式化检查

mvn google-java-format:validate

📌 自动修复格式问题

mvn google-java-format:format

进阶解决方案：高级集成策略

方案A：Git钩子集成

# 创建pre-commit钩子
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/sh
# 获取暂存区的Java文件
STAGED_FILES=$(git diff --cached --name-only -- '*.java')

if [ -n "$STAGED_FILES" ]; then
    # 对暂存区文件执行格式化
    echo "Formatting staged Java files..."
    echo "$STAGED_FILES" | xargs java -jar /path/to/google-java-format-1.17.0-all-deps.jar --replace
    
    # 将格式化后的文件重新暂存
    echo "$STAGED_FILES" | xargs git add
fi

exit 0
EOF

# 赋予执行权限
chmod +x .git/hooks/pre-commit

方案B：CI流水线配置（GitHub Actions示例）

name: Code Format Check

on: [pull_request]

jobs:
  format-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: Check code format
        run: |
          # 下载Google Java Format
          wget https://github.com/google/google-java-format/releases/download/v1.17.0/google-java-format-1.17.0-all-deps.jar
          
          # 检查格式
          find . -name "*.java" -exec java -jar google-java-format-1.17.0-all-deps.jar --dry-run {} \;
          
          # 如果有未格式化的文件，此命令将返回非零 exit code
          if [ $? -ne 0 ]; then
            echo "The following files need formatting:"
            find . -name "*.java" -exec java -jar google-java-format-1.17.0-all-deps.jar --dry-run {} \;
            exit 1
          fi

预防措施

⚠️ 在开发团队中强制使用Git钩子，确保提交前代码已格式化 ⚠️ 在CI流程中设置格式化检查为必须通过的步骤 ⚠️ 定期更新构建工具插件版本，保持与最新版Google Java Format兼容 ⚠️ 在开发环境和CI环境中使用相同版本的工具，避免环境差异

问题自检清单

  • [ ] 构建工具中是否正确配置了格式化插件
  • [ ] Git钩子是否已在团队所有成员的环境中安装
  • [ ] CI流水线是否包含格式化检查步骤
  • [ ] 本地与CI环境使用的工具版本是否一致
  • [ ] 是否为格式化检查设置了合理的超时时间

五、错误处理与优化类问题：从异常捕获到性能调优

场景引入

当你处理一个包含数千个Java文件的大型项目时，格式化过程可能需要几分钟甚至更长时间，或者在处理某些特定文件时反复失败并抛出异常。这些情况需要深入的错误处理和性能优化策略。

问题现象

  • 格式化过程抛出FormatterException异常
  • 处理大型项目时速度极慢
  • 某些特定文件始终无法格式化成功
  • 内存占用过高导致工具崩溃

原因分析

  1. 代码结构复杂：包含复杂泛型、匿名类或深层嵌套的代码可能难以格式化
  2. 工具限制：Google Java Format对某些特殊语法结构支持有限
  3. 资源不足：默认JVM内存设置不足以处理大型项目
  4. 文件过大：单个超大Java文件超出工具处理能力
  5. 并发问题：多线程格式化时出现资源竞争

分级解决方案

基础解决方案：异常处理与基本优化

📌 异常捕获与处理

import com.google.googlejavaformat.java.Formatter;
import com.google.googlejavaformat.java.FormatterException;

public class CodeFormatter {
    public String formatJavaCode(String sourceCode) {
        try {
            // 创建Formatter实例
            Formatter formatter = new Formatter();
            // 尝试格式化代码
            return formatter.formatSource(sourceCode);
        } catch (FormatterException e) {
            // 处理格式化异常
            System.err.println("格式化失败: " + e.getMessage());
            // 返回原始代码或部分格式化结果
            return sourceCode;
        } catch (Exception e) {
            // 处理其他异常
            System.err.println("发生意外错误: " + e.getMessage());
            return sourceCode;
        }
    }
}

📌 增加JVM内存分配

# 增加堆内存到2GB
java -Xmx2g -jar google-java-format-1.17.0-all-deps.jar --replace large-project/

进阶解决方案：高级优化策略

方案A：分批次处理大型项目

# 创建按模块分批次处理的脚本
#!/bin/bash
MODULES=("core" "service" "api" "common")

for module in "${MODULES[@]}"; do
    echo "Formatting module: $module"
    find "$module" -name "*.java" -exec java -jar google-java-format-1.17.0-all-deps.jar --replace {} \;
    echo "Completed module: $module"
done

方案B：跳过无法格式化的文件

#!/bin/bash
# 格式化所有Java文件，但跳过格式化失败的文件
find . -name "*.java" | while read file; do
    echo "Formatting $file"
    if java -jar google-java-format-1.17.0-all-deps.jar --replace "$file"; then
        echo "Successfully formatted $file"
    else
        echo "⚠️ Failed to format $file, skipping"
        # 记录失败的文件以便后续处理
        echo "$file" >> format-failures.txt
    fi
done

方案C：并行处理提高速度

# 使用xargs并行处理文件，-P参数指定并行数
find . -name "*.java" | xargs -P 4 -I {} java -jar google-java-format-1.17.0-all-deps.jar --replace {}

预防措施

⚠️ 对于大型项目，设置合理的JVM内存参数（通常至少1GB） ⚠️ 监控并记录格式化失败的文件，单独处理这些特殊情况 ⚠️ 避免创建过大的Java文件（建议单个文件不超过1000行） ⚠️ 对特别复杂的代码段考虑添加@formatter:off和@formatter:on注释暂时禁用格式化

问题自检清单

  • [ ] 是否正确捕获并处理了FormatterException
  • [ ] 是否为大型项目分配了足够的内存
  • [ ] 是否对无法格式化的文件进行了记录和单独处理
  • [ ] 是否避免了创建过大的Java文件
  • [ ] 是否对格式化过程进行了性能监控和优化

底层机制解析

1. Google Java Format的工作原理

Google Java Format采用了一种基于抽象语法树(AST)的格式化方法，与传统的基于正则表达式的格式化工具有着本质区别：

  1. 解析阶段：工具首先将Java源代码解析为AST，这一过程与Java编译器的前端处理类似
  2. 规范化阶段：将AST转换为一种规范化的中间表示形式，消除原始代码中的格式信息
  3. 重新生成阶段：根据Google Java风格指南，从规范化的中间表示重新生成代码

这种方法的优势在于能够正确理解代码结构，处理复杂的语法场景，避免简单正则替换可能导致的错误。核心实现位于core/src/main/java/com/google/googlejavaformat/java/Formatter.java中，通过formatSource方法完成整个格式化流程。

2. JDK内部API依赖机制

Google Java Format需要访问JDK内部的编译器API（如com.sun.tools.javac包中的类）来解析Java代码，这也是为什么在JDK 9及以上版本中需要添加--add-exports参数的原因：

// 核心解析代码示例（简化版）
import com.sun.tools.javac.api.JavacTool;
import com.sun.tools.javac.tree.JCTree;

public class JavaInput {
    public static JCTree parse(String source) {
        JavacTool javacTool = JavacTool.create();
        // 使用JDK内部API解析源代码为AST
        // ...
    }
}

随着Java模块化系统的引入，这些内部API不再默认对外部可见，因此需要显式导出这些包给未命名模块。这一机制确保了工具能够访问必要的编译器功能，同时保持JDK的模块化隔离。

常见误区对比表

常见误区 正确做法 原因分析
使用--replace参数时不先提交代码 格式化前提交或创建分支 --replace会直接修改文件，未提交的更改可能被覆盖
认为最新版本总是最好的 使用与项目JDK版本匹配的工具版本 新版本可能不支持旧JDK，或引入不兼容变更
全局应用格式化而不测试 先在测试环境验证格式化效果 大规模格式化可能引入意外变更，需要测试验证
忽略格式化失败的文件 记录并分析失败原因 格式化失败通常暗示代码存在问题或特殊结构
仅依赖IDE插件进行格式化 结合命令行工具和CI检查 确保所有团队成员和构建流程使用一致的格式化标准

实用配置模板

1. Maven插件配置模板

<plugin>
    <groupId>com.google.googlejavaformat</groupId>
    <artifactId>google-java-format-maven-plugin</artifactId>
    <version>1.17.0</version>
    <executions>
        <!-- 在编译前执行格式化检查 -->
        <execution>
            <id>format-check</id>
            <phase>compile</phase>
            <goals>
                <goal>validate</goal>
            </goals>
        </execution>
        <!-- 提供手动格式化命令 -->
        <execution>
            <id>format</id>
            <goals>
                <goal>format</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <!-- 排除自动生成的代码 -->
        <exclude>**/generated/**</exclude>
        <!-- 设置Java版本 -->
        <javaVersion>17</javaVersion>
    </configuration>
</plugin>

2. 命令行工具封装脚本（bash）

#!/bin/bash
# 文件名: gjf
# Google Java Format工具封装脚本

# 工具版本
VERSION="1.17.0"
# JAR文件路径，可根据实际情况修改
JAR_PATH="$HOME/tools/google-java-format-${VERSION}-all-deps.jar"

# 检查JAR文件是否存在
if [ ! -f "$JAR_PATH" ]; then
    echo "Google Java Format JAR文件未找到，正在下载..."
    mkdir -p "$(dirname "$JAR_PATH")"
    wget "https://github.com/google/google-java-format/releases/download/v${VERSION}/google-java-format-${VERSION}-all-deps.jar" -O "$JAR_PATH"
fi

# 必要的JVM参数
JVM_ARGS="--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED"

# 执行格式化命令
java $JVM_ARGS -jar "$JAR_PATH" "$@"

3. Git预提交钩子配置

#!/bin/sh
# .git/hooks/pre-commit

# Google Java Format路径
GJF_PATH="$HOME/tools/google-java-format-1.17.0-all-deps.jar"

# 检查工具是否存在
if [ ! -f "$GJF_PATH" ]; then
    echo "Error: Google Java Format not found at $GJF_PATH"
    echo "Please install it or update the path in the pre-commit hook"
    exit 1
fi

# JVM参数
JVM_ARGS="--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED"
JVM_ARGS+=" --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED"

# 获取暂存区的Java文件
STAGED_FILES=$(git diff --cached --name-only -- '*.java' | grep -v 'generated/')

if [ -n "$STAGED_FILES" ]; then
    echo "Running Google Java Format on staged files..."
    
    # 对每个文件进行格式化
    echo "$STAGED_FILES" | while read file; do
        if [ -f "$file" ]; then
            java $JVM_ARGS -jar "$GJF_PATH" --replace "$file"
            # 将格式化后的文件重新暂存
            git add "$file"
        fi
    done
fi

exit 0

问题诊断流程图

  1. 工具无法启动

    • 检查Java版本是否兼容
    • 检查JAR文件是否存在且完整
    • 检查是否提供了必要的JVM参数（特别是JDK 9+）
    • 检查文件权限

  2. 格式化无效果

    • 确认使用了--replace参数
    • 检查文件是否有语法错误
    • 验证文件编码是否为UTF-8
    • 尝试使用--dry-run查看是否有需要格式化的内容

  3. IDE插件不工作

    • 确认插件已启用
    • 检查IDE版本与插件版本兼容性
    • 尝试重启IDE
    • 清除IDE缓存
    • 重新安装插件

  4. CI检查失败

    • 对比本地与CI环境的工具版本
    • 检查是否所有文件都已格式化
    • 确认CI环境的JVM参数配置
    • 检查是否有平台相关的格式差异

  5. 性能问题

    • 增加JVM内存分配
    • 分批次处理文件
    • 使用并行处理
    • 排除大型自动生成文件
google-java-format
Reformats Java source code to comply with Google Java Style.
项目地址：https://gitcode.com/gh_mirrors/goo/google-java-format
登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
docsdocs
暂无描述
Dockerfile
720
4.62 K
pytorchpytorch
Ascend Extension for PyTorch
Python
594
743
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
424
372
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
983
974
atomcodeatomcode
Claude Code 的开源替代方案。连接任意大模型，编辑代码，运行命令，自动验证 — 全自动执行。用 Rust 构建，极致性能。 ｜ An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started
Rust
872
126
kernelkernel
deepin linux kernel
C
29
16
flutter_flutterflutter_flutter
暂无简介
Dart
966
244
Oohos_react_native
React Native鸿蒙化仓库
C++
345
390
MindSpeed-LLMMindSpeed-LLM
昇腾LLM分布式训练框架
Python
158
187
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot，Spring Security，JWT，Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.64 K
964