一文详解银河麒麟配置容器运行时及gVisor(runsc)、Kata(runv)详细指南

容器运行时介绍

容器运行时核心概念与分类

容器运行时（Container Runtime）是管理容器生命周期（创建、启动、停止、删除）和资源隔离的核心组件，通过与操作系统内核协作实现容器化环境。根据功能层级和技术实现，容器运行时可分为以下三类。

高层运行时（High-Level Runtime）

作用：

高层运行时主要负责镜像管理（如下载、解压、转换镜像）、容器生命周期管理（如创建、启动、停止容器）、存储和网络配置等高级功能。它为容器运行提供基础环境准备，并将镜像转换为低层运行时所需的文件系统和配置。

核心特点：

  • 提供镜像仓库交互、镜像层解压等能力。
  • 集成容器编排系统（如Kubernetes），提供标准化的API接口。
  • 通常与低层运行时配合使用，形成完整的容器管理链。

代表产品与技术：

  1. Docker Engine

    特点：包含高层运行时（Dockerd）和低层运行时（runc），提供完整的容器生态（如镜像构建、网络配置）。但因多层封装导致复杂性较高，逐渐被替代

    应用场景：用于应用、镜像测试，或小规模容器管理

  2. Containerd

    特点：由Docker分离出的轻量级运行时，专注于核心功能，性能高且稳定。支持OCI标准，与Kubernetes深度集成，已成为Kubernetes默认运行时之一

    应用场景：生产环境、大规模容器集群管理

  3. CRI-O

    特点：专为Kubernetes设计的轻量级运行时，符合CRI（容器运行时接口）规范。直接调用低层运行时（如runc），简化与Kubernetes的集成，资源消耗低

    应用场景：Kubernetes环境中替代Docker，适合需要精简架构的场景。

低层运行时（Low-Level Runtime）

作用：

低层运行时直接与宿主机操作系统交互，负责容器进程的隔离与执行，包括设置Linux Namespace、Cgroups资源限制、文件系统挂载等底层操作。它是实际启动容器进程的核心组件。

核心特点：

  • 轻量级，仅关注进程隔离和资源控制。
  • 遵循OCI（开放容器标准）规范，提供标准化接口

代表产品与技术：

  1. runc

    特点：最广泛使用的低层运行时，基于Namespace和Cgroups实现容器隔离。作为Docker和Containerd的默认执行引擎，启动速度快但安全性较低（共享内核）。

    应用场景：通用容器场景，需高性能但隔离要求不高的环境

  2. runv（Kata Containers/Firecracker）

    特点：基于虚拟化技术（如KVM），通过轻量级虚拟机（MicroVM）实现强隔离。适合多租户和高安全需求场景，但启动速度较慢（约100ms）

    应用场景：金融、云服务等需要严格安全隔离的环境

  3. runsc（gVisor）

    特点：通过拦截系统调用实现沙箱化隔离，安全性介于runc和runv之间。资源消耗低，但兼容性受限（部分系统调用不支持）

    应用场景：对安全有中等要求的容器化应用，如公有云多租户服务。

沙盒/虚拟化运行时（Sandboxed Runtime）

作用：

通过虚拟化或沙盒技术增强安全性，适用于多租户和高敏感场景。

代表产品与技术：

  1. Kata Containers

    特点：通过轻量级虚拟机（MicroVM）实现容器隔离，每个容器运行在独立的虚拟机内核中，避免了共享宿主机内核的安全风险。这种设计可防御容器逃逸攻击，尤其适用于金融、医疗等对数据隐私要求极高的场景。例如，其与英特尔 VT 技术结合，实现了网络、I/O 和内存的硬件级隔离

  2. gVisor

    特点：通过用户空间实现的“沙箱内核”（Sentry）拦截容器系统调用，减少了攻击面。其内核功能由 Go 语言实现，内存安全特性降低了漏洞风险，且无需依赖硬件虚拟化技术，资源消耗低于传统虚拟机

与Kubernetes协作

Kubernetes通过容器运行时接口（CRI）统一管理不同运行时，典型流程如下：

  1. kubelet接收Pod创建请求，通过CRI接口调用高层运行时（如containerd）。
  2. 高层运行时拉取镜像并解压为rootfs，生成容器配置（config.json）。
  3. 低层运行时（如runc）根据配置启动容器进程，设置Namespace和Cgroups。
  4. 安全沙箱运行时（如Kata）通过虚拟化层隔离容器，提供额外安全保护。

运行时总结

运行时类型 代表工具 优势 局限性
高层运行时 Docker 轻量、功能丰富 性能较低，安全性风险
高层运行时 Containerd 轻量、高性能、Kubernetes原生支持 功能相对基础，需搭配其他工具
高层运行时 CRI-O 专为Kubernetes优化，资源消耗低 社区生态较新，生产实践较少
低层运行时 runc 启动快、资源占用低 共享内核，隔离性弱
低层运行时 runv（Kata） 强隔离（虚拟机级） 启动速度慢，资源消耗高
低层运行时 runsc（gVisor） 沙箱化安全，轻量 系统调用兼容性有限

容器运行时应用

上文介绍完概念，那么这些个底层运行时如何在生产中与高层运行时配合使用呢？

下文以docker、containerd、gVisor、Kata为例来演示，以及和kubernetes的配置使用。

运行时部署

本示例中所有部署均采取二进制方式来演示。

系统环境及组件版本介绍

系统环境

# nkvers 
############## Kylin Linux Version #################
Release:
Kylin Linux Advanced Server Release V10 (Trading)

Kernel:
4.19.90-89.15.v2401.ky10.x86_64

Build:
Kylin Linux Advanced Server
Release V10 SP3 2403/(Trading)-x86_64-Build03/20240813
#################################################

组件版本介绍

服务名称 版本 备注
Docker 27.5.1
Containerd 1.7.25
runsc release-20250331.0
containerd-shim-runsc-v1 1.6.36
kata-runtime 3.1.3
containerd-shim-kata-v2 1.6.8
Kubernetes 1.33.0

containerd运行时部署

二进制包下载地址：https://github.com/containerd/containerd/releases

下载安装

wget https://github.com/containerd/containerd/releases/download/v2.0.4/containerd-2.0.4-linux-amd64.tar.gz
tar xf containerd-2.0.4-linux-amd64.tar.gz && mv ./bin/* /usr/bin/

配置systemd

vim /etc/systemd/system/containerd.service

[Unit]
Description=Containerd Container Runtime
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/bin/containerd
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity                                                                                                            
TasksMax=infinity

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
# 启动并设置开机自启
systemctl enable --now containerd.service

docker运行时部署

二进制包下载地址：https://download.docker.com/linux/static/stable/x86_64/

下载安装

wget https://download.docker.com/linux/static/stable/x86_64/docker-27.5.1.tgz
tar xf docker-27.5.1.tgz
# 这里除去containerd  containerd-shim-runc-v2  ctr三个containerd的文件，其他均mv至/usr/bin/下即可
cd docker && mv docker* runc /usr/bin/

配置systemd

vim /etc/systemd/system/docker.service

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target firewalld.service
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/dockerd --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutStartSec=0
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
Delegate=yes
KillMode=process

[Install]
WantedBy=multi-user.target

--containerd=/run/containerd/containerd.sock，指定containerd sock路径，因为直接复用了上一步自己部署的containerd，并没有使用docker包中自带的containerd服务，所以需要加此配置，这也验证了docker是要调用containerd来实现自己的功能的。

systemctl daemon-reload
# 启动并设置开机自启
systemctl enable --now docker.service

runsc-gVisor运行时配置

官方部署文档：https://gvisor.dev/docs/user_guide/install/

下载安装

vim install_gvisor.sh

(
  set -e
  ARCH=$(uname -m)
  URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}
  wget ${URL}/runsc ${URL}/runsc.sha512 \
    ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
  sha512sum -c runsc.sha512 \
    -c containerd-shim-runsc-v1.sha512
  rm -f *.sha512
  chmod a+rx runsc containerd-shim-runsc-v1
  sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin
)

保存执行

chmod +x install_gvisor.sh && ./install_gvisor.sh

kata-containers运行时部署

二进制包下载地址：https://github.com/kata-containers/kata-containers/releases

下载安装

目前kata-containers最新版本为3.15.0，由于银河麒麟v10的自带glibc版本=2.28版本，新版本的kata需要glibc>2.34版本，银河麒麟升级glibc是一个较麻烦的动作，故此安装非最新版本。

kata-containers v3.12.0即可满足glibc的版本问题，但安装kata-static-3.12.0后，虽然检查运行环境能够通过，但在实际使用containerd创建kata运行时容器时，却一直报连接超时的问题，containerd及kata详细报错如下：

level=info arch=amd64 arguments="\\"features\"" commit=39bf10875b4f321d05e6e6a97bd5f0e62ad37993 name=kata-runtime pid=1048 source=runtime version=3.12.0
level=error msg="Invalid command \\"features\"" arch=amd64 name=kata-runtime pid=1048 source=runtime
level=info msg="loaded configuration" arch=amd64 file=/opt/kata/share/defaults/kata-containers/configuration-qemu.toml format=TOML name=kata-runtime pid=2129 source=katautils
level=info msg="IOMMUPlatform is disabled by default." arch=amd64 name=kata-runtime pid=2129 source=katautils
level=info arch=amd64 arguments="\\"features\"" commit=39bf10875b4f321d05e6e6a97bd5f0e62ad37993 name=kata-runtime pid=2129 source=runtime version=3.12.0
level=error msg="Invalid command \\"features\"" arch=amd64 name=kata-runtime pid=2129 source=runtime
level=warning msg="Could not add /dev/mshv to the devices cgroup" name=containerd-shim-v2 pid=2674 sandbox=hello-wrold source=cgroups
level=error msg="qemu-system-x86_64: -chardev socket,id=char-33b63cf7ea0559ba,path=/run/vc/vm/hello-wrold/vhost-fs.sock: Failed to connect to '/run/vc/vm/hello-wrold/vhost-fs.sock': Connection refused" name=containerd-shim-v2 pid=2674 qemuPid=2688 sandbox=hello-wrold source=virtcontainers/hypervisor subsystem=qemu

通过查看GitHub issue发现，出现此报错大概率是qemu-system-x86_64和virtiofsd的版本太高，不适配导致的，具体版本如下：

# ./qemu-system-x86_64 -version 
QEMU emulator version 9.1.2 (kata-static)
Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers

# ./virtiofsd -V
virtiofsd 1.8.0

所以最终安装kata-static-3.1.3版本：

wget https://github.com/kata-containers/kata-containers/releases/download/3.1.3/kata-static-3.1.3-x86_64.tar.xz
tar xf kata-static-3.1.3-x86_64.tar.xz && mv ./opt/kata /opt/

检查运行环境

# /opt/kata/bin/kata-runtime check
WARN[0000] Not running network checks as super user      arch=amd64 name=kata-runtime pid=1673 source=runtime                 
System is capable of running Kata Containers                                                                                  
System can currently create Kata Containers

若报错类似以下信息：

# kata-runtime check                                                                                
WARN[0000] Not running network checks as super user      arch=amd64 name=kata-runtime pid=3133 source=runtime                 
ERRO[0000] CPU property not found                        arch=amd64 description="Virtualization support" name=svm pid=3133 sou
rce=runtime type=flag                                                                                                         
WARN[0000] modprobe insert module failed                 arch=amd64 error="exit status 1" module=kvm_amd name=kata-runtime out
put="modprobe: ERROR: could not insert 'kvm_amd': Operation not supported\\n" pid=3133 source=runtime                          
ERRO[0000] kernel property kvm_amd not found             arch=amd64 description="AMD KVM" name=kvm_amd pid=3133 source=runtime
 type=module                                                                                                                  
ERRO[0000] ERROR: System is not capable of running Kata Containers  arch=amd64 name=kata-runtime pid=3133 source=runtime      
ERROR: System is not capable of running Kata Containers

需要打开硬件虚拟化功能，我这里是Virtual Box，执行以下操作即可：

关闭虚拟机，打开硬件虚拟化功能：

image-20250408143346554

VMware也是一样的操作，在设置中配置即可。

配置环境变量

vim ~/.bashrc

export KATA_PATH=/opt/kata/bin/:/opt/kata/libexec/                                                                            
export PATH=$PATH:$KATA_PATH

追加以上信息

source ~/.bashrc

配置软连接

# ln -sv /opt/kata/bin/kata-runtime /usr/local/bin/
'/usr/local/bin/kata-runtime' -> '/opt/kata/bin/kata-runtime'

# ln -sv /opt/kata/bin/containerd-shim-kata-v2 /usr/local/bin/
'/usr/local/bin/containerd-shim-kata-v2' -> '/opt/kata/bin/containerd-shim-kata-v2'

这一步是因为后续使用--runtime io.containerd.kata.v2指定runtime时需要

至此，四种运行时均已部署完毕，k8s部署过程此文档不再赘述，可参考之前的博文，或者直接参考官网部署文档进行部署。

下文开始配合使用底层、高层运行时。

运行时的应用

docker配置runsc和kata运行时

配置docker识别runsc运行时

/usr/local/bin/runsc install

执行完毕后，/etc/docker/daemon.json会生成以下配置：

    "runtimes": {
        "runsc": {
            "path": "/usr/local/bin/runsc"
        }
    }

重新加载docker：

 systemctl reload docker

查看是否识别runsc：

# docker info | grep Runtimes
 Runtimes: io.containerd.runc.v2 runc runsc

配置docker识别kata运行时

vim /etc/docker/daemon.json

    "runtimes": {
        "runsc": {
            "path": "/usr/local/bin/runsc"
        },
        "kata-runtime": {
            "path": "/opt/kata/bin/kata-runtime"
        }
    }

重新加载docker：

systemctl reload docker.service

查看是否识别kata：

# docker info | grep Runtimes
 Runtimes: io.containerd.runc.v2 kata-runtime runc runsc

为docker临时指定低层运行时运行容器

# 临时使用runsc启动容器
docker run -dit --rm --name test-runsc --runtime=runsc nginx

# 临时使用kata启动容器
docker run -dit --rm --name=test-kata --runtime=kata-runtime nginx

查看容器Runtime：

# docker inspect test-runsc | grep Runtime 
            "Runtime": "runsc",

# docker inspect test-kata | grep Runtime 
            "Runtime": "kata-runtime",

但是在基于kata运行时创建容器时，出现了以下报错：

# docker run -dit --rm --name=test-kata --runtime=kata-runtime nginx
db6e291450f6c57519b8e87f179a63dd0760d9d07ced84ec2c540f96595a0b91
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: Invalid command "create": unknown.

通过GitHub的issue排查到，报次错的问题大概率为kata的docker不兼容的问题导致的，参考链接：

https://github.com/kata-containers/runtime/issues/3038
https://github.com/kata-containers/kata-containers/issues/10223

但是这个issue提及的是kata2.x版本，本文已经在使用kata3.x版本。

我已经在issue末尾跟评了，暂时还没有收到回复，所以是什么原因导致的，暂时不得而知。

为docker指定默认低层运行时

vim /etc/docker/daemon.json

    "runtimes": {
        "runsc": {
            "path": "/usr/local/bin/runsc"
        },
        "kata-runtime": {
            "path": "/opt/kata/bin/kata-runtime"
        }
    },
    "default-runtime": "runsc"  //默认运行时配置

重新加载配置，查看结果：

# systemctl reload docker.service 
# docker info | grep Runtime 
 Runtimes: io.containerd.runc.v2 kata-runtime runc runsc
 Default Runtime: runsc

containerd配置runsc和kata运行时

安装配置crictl/nerctl

官网地址：https://github.com/containerd/containerd/blob/main/docs/getting-started.md#interacting-with-containerd-via-cli

wget https://github.com/containerd/nerdctl/releases/download/v2.0.4/nerdctl-2.0.4-linux-amd64.tar.gz
tar xf nerdctl-2.0.4-linux-amd64.tar.gz -C /usr/local/bin/

wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.32.0/crictl-v1.32.0-linux-amd64.tar.gz
tar xf crictl-v1.32.0-linux-amd64.tar.gz -C /usr/local/bin/

cat >/etc/crictl.yaml <

添加补全：

echo 'source <(nerdctl completion bash)' >> /etc/bashrc
echo 'source <(crictl completion bash)' >> /etc/bashrc
nerdctl completion bash
crictl completion bash
source /etc/bashrc

配置containerd识别runsc、kata运行时

gVisor官方文档：https://gvisor.dev/docs/user_guide/containerd/quick_start/

kata官方文档：https://github.com/kata-containers/kata-containers/blob/main/docs/how-to/containerd-kata.md#configuration

生成containerd配置文件：

mkdir /etc/containerd/
containerd config default > /etc/containerd/config.toml

修改config.toml，如果containerd版本>2.0则应该是：

vim /etc/containerd/config.toml

    [plugins.'io.containerd.cri.v1.runtime'.containerd]
# 默认runtime
      default_runtime_name = 'runc'
# runc
      [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes]
        [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
          runtime_type = 'io.containerd.runc.v2'
          sandboxer = 'podsandbox'
          io_type = ''

          [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
            BinaryName = ''
# kata-runtime
        [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.kata-runtime]
          runtime_type = "io.containerd.kata.v2"
          [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.kata-runtime.options]
            BinaryName = "/opt/kata/bin/containerd-shim-kata-v2"
# runsc
        [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runsc]
          runtime_type = "io.containerd.runsc.v1"
          [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runsc.options]
            BinaryName = "/usr/local/bin/runsc"

如果是containerd<2>则为：

vim /etc/containerd/config.toml

    [plugins."io.containerd.grpc.v1.cri".containerd]
# 默认运行时
      default_runtime_name = "runc"

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
# runc
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v2"

          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            BinaryName = ""
# runsc
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
          runtime_type = "io.containerd.runsc.v1"
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc.options]
            BinaryName = "/usr/local/bin/runsc"
# kata-runtime
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-runtime]
          runtime_type = "io.containerd.kata.v2"
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-runtime.options]
            BinaryName = "/opt/kata/bin/containerd-shim-kata-v2"

配置完毕，重启containerd：

systemctl restart containerd.service

验证是否加载运行时：

# crictl info 
     "runtimes": {
        "kata": {
          "options": {
            "BinaryName": "/opt/kata/bin/containerd-shim-kata-v2"
          },
          "runtimeType": "io.containerd.kata.v2",
          "sandboxMode": "podsandbox",
          "snapshotter": ""
        },
        "runc": {
          "ContainerAnnotations": [],
          },
        },
        "runsc": {
          "options": {
            "BinaryName": "/usr/local/bin/runsc"
          },
        }

为containerd指定低层运行时运行容器

修改默认运行时：

vim /etc/containerd/config.toml

    [plugins.'io.containerd.cri.v1.runtime'.containerd]
      default_runtime_name = 'runsc'

systemctl restart containerd.service

临时指定并运行：

runsc：

ctr i pull docker.io/library/nginx:latest
ctr run --runtime io.containerd.runsc.v1 -t --rm docker.io/library/nginx:latest nginx-runsc

kata-runtime：

ctr run --runtime io.containerd.kata.v2 -t --rm docker.io/library/nginx:latest nginx-kata

查看容器runtime：

# ctr c ls 
CONTAINER      IMAGE                             RUNTIME                   
nginx-kata     docker.io/library/nginx:latest    io.containerd.kata.v2     
nginx-runsc    docker.io/library/nginx:latest    io.containerd.runsc.v1

内核对比：

# nerdctl exec -it nginx-kata uname -r 
5.19.2
# nerdctl exec -it nginx-runsc uname -r 
4.4.0

## 宿主机内核
# uname -r 
4.19.90-89.15.v2401.ky10.x86_64

Kubernetes配置runsc和kata运行时

gVisor官方文档：https://gvisor.dev/docs/user_guide/containerd/quick_start/

kata官方文档：https://github.com/kata-containers/kata-containers/blob/main/docs/how-to/how-to-use-k8s-with-containerd-and-kata.md

本文档不再演示k8s部署过程，可参考博主其他博文或直接参考k8s官方文档进行部署。

在使用k8s创建runsc和kata容器时，前提条件是containerd已经配置好runsc和kata的runtime，也就是以上containerd配置runsc和kata运行时的步骤。

配置Kubelet 以使用 containerd

在kubernetes v1.24之后，默认的运行时就是containerd，可以再次检查一遍，如不是，需修改。

# sudo mkdir -p  /etc/systemd/system/kubelet.service.d/
# cat << EOF Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock">

如修改，需重新加载：

# sudo systemctl daemon-reload

配置HTTP代理（可选）

如果使用代理，请使用以下脚本为 docker、Kubelet 和 containerd 配置代理：

# 配置环境变量
services="
kubelet
containerd
docker
"

# 编辑配置文件
for service in ${services}; do

    service_dir="/etc/systemd/system/${service}.service.d/"
    sudo mkdir -p ${service_dir}

    cat << EOF Environment="HTTP_PROXY=${http_proxy}" Environment="HTTPS_PROXY=${https_proxy}" Environment="NO_PROXY=${no_proxy}">

配置RuntimeClass

默认情况下，所有 Pod 都使用 containerd 中配置的默认运行时创建。从 Kubernetes v1.12 开始，用户可以使用RuntimeClass。

runsc：

cat <

kata：

cat <

查看RuntimeClass：

kubectl get RuntimeClass

指定RuntimeClass创建Pod

runsc：

cat <

kata：

cat <

检查 Pod 是否正在运行

# kubectl get pods
# ctr c ls

结语

以上就是对常用的高层、底层运行时的介绍以及基于银河麒麟操作系统的操作演示，容器技术和国产操作系统都在如火如荼的发展，两者不可避免的会擦起火花，尽管国内信创行业正在高速的发展，但是无可避免的会出现很多使用问题。遇到问题，面对问题，解决问题，这也是我们每个技术人“享受”的过程。

From:https://www.cnblogs.com/v-fan/p/18843188
塔克拉玛攻城狮
相关文章
  1. 协同过滤推荐算法的入门案例
    Mysticbinary·6天前
    协同过滤推荐算法的入门案例
    编程知识
  3. Windows系统优化 3-清理预安装软件
    小小先生好无情·6天前
    Windows系统优化 3-清理预安装软件
    编程知识
  4. 在SqlSugar的开发框架中增加对低代码EAV模型（实体-属性-值）的WebAPI实现支持
    伍华聪·6天前
    在SqlSugar的开发框架中增加对低代码EAV模型（实体-属性-值）的WebAPI实现支持
    编程知识
  5. WindRunnerMax·6天前
    基于 OT-JSON 与 Immer 设计低代码/富文本场景的状态管理方案
    在复杂应用中，例如低代码、富文本编辑器的场景下，数据结构的设计就显得非常重要，这种情况下的状态管理并非是redux、mobx等通用解决方案，而是需要针对具体场景进行定制化设计，那么在这里我们来尝试基于Immer以及OT-JSON实现原子化、可协同、高扩展的应用级状态管理方案。 描述 将Immer与O
    编程知识
  6. 聊聊SpringAI流式输出的底层实现？
    磊哥|www.javacn.site·6天前
    聊聊SpringAI流式输出的底层实现？
    编程知识
  8. victor.x.qu·6天前
    如何基于 Kestrel 实现 socks5 代理
    前言 之前做了个轮子NZOrz, 本来打算慢慢参照Kestrel和Yarp长久地写着玩 奈何川普上台，关税，订婚案，自身和钱包等等各种乐子层出不穷，无暇慢悠悠地写轮子玩 还有有些盆友也想知道能否直接使用 Kestrel 来实现L4的处理， 所以为了2025年轻松一些，重新基于 Kestrel 实现了
    编程知识
  9. 使用这个工具，基于代码仓库直接生成教程文档，感觉比我自己写的还好
    mingupupup·6天前
    使用这个工具，基于代码仓库直接生成教程文档，感觉比我自己写的还好
    编程知识
  10. 探秘Transformer系列之（30）--- 投机解码
    投机解码 - 罗西的思考·5天前
    探秘Transformer系列之（30）--- 投机解码
    编程知识