AKS 不是安装在 Windows Server 上，而是运行在 Windows Server 之上的 Azure 平台能力

XUHUOJUN2026-07-20 17:27

未经同意，请勿转载！

TL;DR ：Windows Server 本身不是 AKS 的运行平台，但这并不意味着 Windows Server 技术栈不能承载 AKS。Azure Stack Hub、Azure Local 都是基于 Windows Server 构建并叠加 Azure 控制平面、资源管理、生命周期管理与 Azure Arc 能力后才成为 Azure 平台形态，进而提供 AKS 服务能力。

因此，问题的边界不是 "Windows Server vs AKS"，而是 "裸 Windows Server" vs "Windows Server + Azure 平台形态"。本文围绕这一边界展开。

术语约定：

  • 全文首次出现使用 AKS enabled by Azure Arc（微软官方命名）；
  • 当讨论 Azure Local 场景的本地 AKS 时，本系列简称 Azure Local AKS------不构成对 AKS enabled by Azure Arc 产品范围的覆盖；
  • 全文不再混用 "AKS Arc" / "AKS on Azure Local" 等非正式变体。
  • AKS enabled by Azure Arc 的运行平台范围包括 Azure Local、Azure Stack HCI（历史名称）、VMware vSphere 等 Azure Arc 支持的环境------不专属 Azure Local。

引言：被反复追问的"Windows Server 能不能装 AKS"

关于 Windows Server 与 AKS 的关系，最常见的提问是：

既然 Windows Server 2022/2025 能跑 Docker，Azure Stack Hub 又能提供 Kubernetes 服务，那能不能在普通 Windows Server 上装一个 AKS？

这是一个边界问题，需要先区分：

  • "Windows Server 能不能运行 Kubernetes" ------答案是可以
  • "普通 Windows Server 能不能提供 AKS 服务能力" ------答案是不可以
  • "Windows Server 技术栈能不能承载 AKS" ------答案是可以，但需要叠加 Azure 平台形态（典型证据：Azure Stack Hub 与 Azure Local）

本文围绕三个核心问题展开：

  1. 为什么裸 Windows Server 不能提供 AKS？
  2. Azure Stack Hub / Azure Local 如何证明 Windows Server 可以承载 AKS？
  3. Azure Local AKS 的本质边界在哪里（不是完全托管 / 也不是 Windows Server Role）？

一、Windows Server 能不能跑 Kubernetes？

答案：可以------裸 Windows Server 完全可以作为 Kubernetes 基础设施的一部分。

但需要正确理解其运行形态。

1.1 路径 A：Linux VM 路线

复制代码 
flowchart TD
    A[Windows Server<br/>宿主] --> B[Hyper-V]
    B --> C[Linux VM]
    C --> D[Kubernetes<br/>kubeadm / Rancher / K3s]

这是最传统的方式：用 Windows Server 跑虚拟化，在 VM 里跑 Linux，再在上面部署 Kubernetes。

1.2 路径 B：Windows Server 作为 Kubernetes Worker Node

复制代码 
flowchart LR
    A[Linux VM<br/>Control Plane] --> B[Linux Worker Node]
    A --> C[Windows Server<br/>Worker Node]
    B --> D[Container]
    C --> E[Windows Container]

Kubernetes 上游社区支持的 Windows Node 包括：

  • Windows Server 2019
  • Windows Server 2022
  • Windows Server 2025（支持范围取决于具体 Kubernetes 版本）

但是有一个Kubernetes 上游架构层面的硬限制：

Kubernetes 控制面（Control Plane）目前仍依赖 Linux------这不是 Windows Server 能力不足，而是 Kubernetes 上游设计的架构选择。

Windows Node 不能运行：kube-apiserver、etcd、scheduler、controller-manager。

1.3 适合哪种应用？

  • ASP.NET Framework 应用
  • IIS 站点
  • 历史遗留的 .NET Framework 服务

这些场景下用 Windows Container 跑 Kubernetes Node 是合理选项。

小结 ：Windows Server 能跑 Kubernetes------这一点没有争议。但能不能跑 K8s ≠ 能不能提供 AKS------见第二章。

二、为什么裸 Windows Server 没有 AKS？

为什么 AKS 不提供 "Install-AKS.ps1" 这种模式？

复制代码 
# 这是不存在的：
Install-AKS.ps1
   ↓
Windows Server
   |
 AKS

2.1 SQL Server 与 Azure SQL 的类比

一个更准确的类比：

|----------------------------|---------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------|
| 用户问的实际问题 | 类似类比 | 答案 |
| Windows Server 能装 AKS 吗 | Windows Server 能装 SQL Server 吗 | ✅ 能装 |
| Windows Server 能成为 AKS 服务吗 | Windows Server 能成为 Azure SQL Database 吗 | ❌ 不能 |
| 原因 | Azure SQL = SQL Server Engine + Cloud Control Plane + Lifecycle Mgmt + Multi-Tenant + Billing | AKS = Kubernetes + Azure Control Plane + Lifecycle Mgmt + Arc + Governance |

理解 SQL Server vs Azure SQL 的边界，就理解了 Kubernetes vs AKS 的边界：

  • Kubernetes------是一个开源容器编排系统，理论上可在任何 Linux/Windows 上运行
  • AKS ------是 Azure 在 Kubernetes 之上叠加完整云平台能力栈后形成的服务

2.2 AKS 包含什么？

AKS（无论是 Azure 公有云 AKS 还是 Azure Local AKS）不是 Kubernetes 二进制，而是一组完整的 Azure 平台能力：

复制代码 
AKS
 =
 Kubernetes Cluster
 + Azure Resource Manager（控制平面）
 + Identity / Entra ID 集成
 + Azure Monitor / Container Insights
 + Microsoft Defender for Containers
 + Azure Policy
 + Lifecycle Management / 升级编排
 + 计量 / 计费 / 多租户隔离（公有云）
 + Arc（本地/边缘场景）

2.3 为什么这些能力不能在裸 Windows Server 上"安装"？

|---------------------------------------------|---------------------|-----------------------|----------------------|
| 能力 | Azure 公有云 AKS | Azure Local AKS | 裸 Windows Server |
| Kubernetes 控制面 | Azure Region 内由微软托管 | 本地 VM 中运行（Arc 编排生命周期） | 用户自建（Linux VM） |
| 生命周期编排（K8s 版本管理 / 升级 / 控制面 HA） | Azure 托管 | Azure Arc 编排 | ❌ 无 |
| ARM 控制平面 / Custom Location | 已具备 | 已具备 | ❌ 无 |
| Arc Resource Bridge | 已具备 | 已具备 | ❌ 无 |
| Azure 集成入口（Monitor / Policy / Defender） | 已具备 | 已具备 | ❌ 无 |
| 与 Azure 控制面的协同连接 | 已具备 | 需 Arc Resource Bridge | ❌ 无 |
| 多租户 / 计量 / 计费（仅公有云） | 具备 | 不具备 | ❌ 无 |

因此：没有这些 Azure 平台能力，AKS 就不是 AKS------它只是 Kubernetes。

这是博客 2 的核心结论 ：AKS 不存在"双击安装"模式，并非因为微软不愿意，而是因为它作为服务，其能力源自 Azure 平台形态本身------而这层平台形态普通 Windows Server 上没有。

2.4 那为什么微软不把 AKS 做成 Windows Server Role？

这是一个合理的问题。可以作以下对比：

|----------|-------------------------|-------------------|
| 维度 | Windows Server | AKS |
| 本质定位 | 操作系统（On-prem Server OS） | Azure 云服务能力 |
| 管理对象 | 单台 / 集群服务器 | 容器化应用生命周期 |
| 运维心智 | 管理员维护基础设施 | 平台服务模型（Azure 自动化） |

如果 AKS 只是：

复制代码 
Windows Server Role
   |
 Install AKS Feature

那微软实际上只能提供：

"Kubernetes 安装工具"

而不是：

"Azure Kubernetes Service"

AKS 的真正价值不是 Kubernetes 本身，而是：

  • Azure Resource Manager（统一控制平面）
  • Azure Identity（Entra ID 集成）
  • Azure Policy（合规治理）
  • Azure Monitor（统一监控）
  • Microsoft Defender for Containers（容器安全）
  • Azure Arc（跨云 / 本地 / 边缘统一管理）
  • Lifecycle Management（生命周期编排）

这些能力必须依附 Azure 平台形态，它们不是操作系统能力，无法通过 Windows Server Role 注入。

三、Azure Stack Hub：Windows Server 技术栈可以承载 AKS 的实证

很多人不知道：Azure Stack Hub 底层就是 Windows Server Datacenter。

复制代码 
flowchart TD
    A[Windows Server Datacenter<br/>底层 OS] --> B[Hyper-V]
    B --> C[Azure Stack Hub Infrastructure VM]
    C --> D[Azure Stack Hub Platform]
    D --> E[Azure Resource Manager]
    D --> F[Fabric Controller]
    D --> G[Resource Providers]
    D --> H[Identity / Portal / Monitoring / Billing]
    G --> I[Compute RP / Network RP / Storage RP / Kubernetes 相关 RP]

展开：

复制代码 
Azure Stack Hub
 =
 Windows Server Datacenter
 + Hyper-V
 + Azure Stack Hub Infrastructure VM
 + Azure Resource Manager
 + Fabric Controller
 + Resource Providers
 + Identity / Portal / Monitoring / Billing
 + ......

3.1 这个事实说明了什么？

Azure Stack Hub 证明了一件事：

Windows Server 技术栈可以承载 AKS / Kubernetes 服务能力------但前提是：在 Windows Server Datacenter 之上，叠加完整的 Azure 平台控制面（ARM / Fabric / RP / Identity / Portal 等）。

也就是说：

  • 裸 Windows Server → ❌ 不能提供 AKS
  • Windows Server + Azure Stack Hub Platform → ✅ 能提供 Kubernetes 服务能力

这构成博客 2 的核心"理论闭环"------也是对"Windows Server 不能跑 AKS"这一表述最有力的反例。

3.2 Azure Stack Hub 上的 Kubernetes 服务形态

注意 ：Azure Stack Hub Kubernetes 服务的提供形态随 Azure Stack Hub 版本演进变化 （历史曾通过 ACS Engine / AKS Engine 等不同模型提供），不同时期、不同版本支持形态不同。

因此本文不绑定特定历史形态做绝对化表述，具体可用形态、当期版本支持情况，请以 Azure Stack Hub 当期官方文档为准。

3.3 Azure Stack Hub ≠ Azure Local

两点提醒：

  • Azure Stack Hub 与 Azure Local 都是 Azure 平台形态的本地延伸 ，但两条独立产品线
  • 目标客户群、部署方式与运营模式不同------本系列其他文章不再展开

四、Azure Local：Azure 平台形态的现代演进

如果说 Azure Stack Hub 是 "基于 Windows Server Datacenter + Hyper-V 构建的小型 Azure 平台"，那么 Azure Local 是同一思路下的现代演进版本------更轻量、更强调云原生、AI 与混合云治理。

4.1 Azure Local 不等于 "Windows Server + 几个组件"

关键澄清：Azure Local 不是 Windows Server 的一个 Role，也不是通过 Windows Server 安装程序升级而来。它是：

复制代码 
Azure Local
 =
 Microsoft Validated HCI Appliance / Platform
 + Windows Server Azure Edition
 + Azure Arc Infrastructure Layer
 + Azure Management Services

因此不能被理解为：

❌ "我买 Windows Server Datacenter，然后安装几个组件就是 Azure Local"

Azure Local 的部署前提包括：

  • OEM Validated Hardware（如 Dell AX / HPE Edgeline 等）
  • Azure Local Deployment Service（专用部署工作流）
  • Azure Arc Registration（注册到 Azure 控制面）
  • Cloud Deployment Workflow（云端部署编排）

4.2 Azure Local 的现代架构分层

复制代码 
flowchart TD
    A[Azure Local] --> B[Microsoft Validated HCI<br/>计算 / 存储 / 网络]
    A --> C[Windows Server Azure Edition<br/>底层 OS]
    A --> D[Azure Local Infrastructure Services<br/>Azure Stack HCI 老版本演进而来]
    A --> E[Azure Arc Connected Infrastructure<br/>云连接 / 治理]
    A --> F[Arc Resource Bridge<br/>本地桥接层]
    A --> G[AKS enabled by Azure Arc<br/>本地 K8s 生命周期编排]

注意 ：v1.1 版本曾把 "Cloud Agent" 单列------但 Cloud Agent 实际只是 Azure Local 基础设施管理组件之一，与 AKS 关系是间接的，因此v1.2 不再单独突出 Cloud Agent。

4.3 Azure Local AKS 的双层架构

Azure Local AKS 不是直接在 Azure Local Host OS 上运行 Kubernetes，而是分层部署：

复制代码 
flowchart TD
    A[Azure Local Cluster] --> B[Arc Resource Bridge<br/>本地桥接]
    B --> C[AKS Management Cluster<br/>由微软管理生命周期]
    C --> D[User Kubernetes Cluster<br/>用户工作负载集群]
    D --> E[Application Pod]
    D --> F[GPU Workload]
    D --> G[Agent / Microservice]

|-----------------------------|--------------------------------------|
| 层 | 负责 |
| Arc Resource Bridge | 把 Azure 控制面请求桥接到本地 |
| AKS Management Cluster | Kubernetes 生命周期管理 / 集群创建与删除 / 升级编排 |
| User Kubernetes Cluster | 用户实际运行应用工作负载（Pod / GPU / Agent 等）的集群 |

企业视角关键启示：

  • 微软负责：Kubernetes 生命周期、控制面部署、升级编排
  • 企业负责：应用生命周期、Node 资源规划、GPU 驱动、StorageClass、网络策略、应用安全

这正是 §六 要进一步展开的本质边界------它是 Kubernetes 生命周期管理能力，而不是完全托管 / PaaS 形态。

4.4 普通 Windows Server vs Azure Local 关键差异

复制代码 
flowchart LR
    subgraph PlainWindowsServer[裸 Windows Server]
        A1[Windows Server OS] --> A2[Hyper-V]
        A2 -.可选.-> A3[Linux VM + 自建 K8s]
    end

    subgraph AzureLocal[Azure Local]
        B1[Microsoft Validated HCI] --> B2[Windows Server Azure Edition] --> B3[Azure Local Infrastructure Services] --> B4[Azure Arc Connected Infrastructure] --> B5[Arc Resource Bridge] --> B6[AKS Management Cluster] --> B7[User Kubernetes Cluster]
    end

两者不是"Windows Server 加与不加 Azure 组件"的关系，而是"裸 OS 平台" vs "经过 Microsoft Validated + OEM 认证 + Azure 控制面集成的 Azure 平台形态"。

五、Windows Server 上可以运行什么 Kubernetes？

主要有三类。

5.1 方案 1：自己部署 Kubernetes

复制代码 
flowchart TD
    A[Windows Server] --> B[Hyper-V]
    B --> C[Linux VM]
    C --> D[Kubernetes]
    D --> E[Container]

    F[kubeadm / Rancher / Kubespray<br/>部署工具] -.-> D
  • 适用范围：开发团队、试验环境
  • 成本：软件成本几乎为零
  • 代价：企业自己维护 K8s 全生命周期

5.2 方案 2：Windows Server 作为 Kubernetes Node

复制代码 
flowchart LR
    A[Linux Control Plane] --> B[Windows Server Node]
    B --> C[Windows Container]
  • 适用：ASP.NET Framework 应用、IIS 历史系统
  • 关键约束：Windows Container 不支持 Linux Container 镜像，反之亦然

5.3 方案 3：第三方 Kubernetes 平台

关键修正（v1.2） ：v1.1 文本中"这些平台可以安装在普通 Windows Server 之上"------这一表述不严谨。

实际情况是：

  • VMware Tanzu ：运行在 VMware vSphere / 裸机 之上，不是装在 Windows Server 上
  • Red Hat OpenShift ：运行在 RHEL / RHCOS / OpenShift Virtualization 之上
  • SUSE Rancher ：管理多个 K8s 集群，本身可部署在 Linux VM 上
  • Mirantis Kubernetes Engine ：主要面向 Linux / vSphere / 公有云部署

Windows Server 在这些方案中最多 作为底层虚拟化平台或作为 .NET 应用工作负载节点参与------不是基础平台。

|----------------------------|----------|---------------------------------|
| 平台 | 厂商 | 主要部署形态 |
| Red Hat OpenShift | Red Hat | RHEL / OpenShift Virtualization |
| SUSE Rancher | SUSE | Linux VM / 多 K8s 集群管理 |
| VMware Tanzu | Broadcom | VMware vSphere / 裸机 |
| Mirantis Kubernetes Engine | Mirantis | Linux / vSphere / 公有云 |

这些平台都不是 "AKS"------前者是用户自建平台，后者（AKS）是 Azure 平台形态上的云服务能力。

六、Azure Local AKS 不是完全托管 / PaaS

这是一个容易被误读的位置------读者很容易把 "Azure Local AKS = 在 Azure 上运行" 想象成 "完全托管 / PaaS"。

6.1 准确描述

Azure Local AKS 不是 Azure 公有云 AKS 那种"完全托管 Kubernetes 服务"，而是 Kubernetes 生命周期管理能力。

6.2 微软负责 vs 企业负责

|----------|-----------------------------------------------------------|
| 责任方 | 负责项 |
| 微软负责 | Kubernetes 生命周期 / 控制面部署 / 升级编排 / Azure Arc 集成 |
| 企业负责 | 应用生命周期 / Node 资源规划 / GPU 驱动栈 / StorageClass / 网络策略 / 应用安全 |

具体细分：

微软负责（生命周期的"平台工程"）
  • ✅ Kubernetes API Server / etcd 部署与升级编排
  • ✅ 节点池（Node Pool）的生命周期管理
  • ✅ 与 Azure 服务（Monitor / Policy / Defender）的集成入口
  • ✅ Kubernetes 组件版本兼容性协调
  • ✅ 证书轮换 / 控制面 HA
企业负责（工作负载的"应用工程"）
  • ✅ 规划 Kubernetes 版本升级窗口
  • ✅ 选择节点池规模与节点 VM 规格
  • ✅ 管理工作负载兼容性（应用是否能在新 K8s 版本上运行）
  • ✅ 管理应用自身的升级与回滚
  • ✅ 自行负责 K8s 节点 VM 的 OS 镜像、GPU 驱动栈、NVIDIA Driver / CUDA / Container Runtime、CNI / NetworkPolicy、StorageClass
  • ✅ 应用层 Deployment / Service / Ingress / RBAC 等 YAML 编排

核心判断 ：Azure Local AKS 降低的是应用交付复杂度 与平台工程复杂度，而不是消除所有运维------这一点与 Azure App Service / Azure Container Apps（公有云 PaaS 形态）有本质区别。

七、三条可选路径的核心对比

如果企业现有：Windows Server 2025 Datacenter + Hyper-V + Storage Spaces，想跑 AI Agent / RAG / 微服务 / Kubernetes 应用，可选路径如下：

7.1 路径 A：普通 Windows Server + 自建 Kubernetes

复制代码 
flowchart LR
    A[Windows Server] --> B[Linux VM] --> C[自建 Kubernetes]
  • 适合：开发团队、小规模试验
  • 代价：自己维护 K8s 全栈
  • 注意：与企业 AKS 治理模型不统一

7.2 路径 B：Azure Local + Azure Local AKS

复制代码 
flowchart LR
    A[Azure Local] --> B[AKS enabled by Azure Arc] --> C[AI / Cloud Native Apps]
  • 适合：企业生产、长期演进
  • 优势：Azure Arc 生命周期编排 + Azure 治理闭环
  • 注意：需满足 Azure Local OEM 认证与硬件 Support Matrix

7.3 路径 C：第三方 HCI + Kubernetes

|----------------------------------|----------------------|
| HCI 平台 | 对应 Kubernetes 方案 |
| Nutanix | Nutanix Karbon |
| VMware vSphere | Tanzu |
| Red Hat OpenShift Virtualization | OpenShift（独立产品） |

  • 适合：已有特定 HCI 栈的企业
  • 注意：与 Azure Arc 治理闭环不互通

7.4 路径对比表

|---------------------------|-----------|----------------------------|----------|
| 关注点 | 路径 A | 路径 B | 路径 C |
| Azure Hybrid Cloud 治理 | ❌ | ✅ | ❌ |
| 极低成本 / 不依赖 Azure | ✅ | ❌ | ✅ |
| 企业生产长期演进 | ⚠️ 需要团队能力 | ✅ | ✅ |
| 已有特定 HCI 栈 | ❌ | ⚠️（OEM 迁移） | ✅ |
| AI / GPU 资源池化 | ⚠️ 自建 | ✅（依 OEM 认证） | ⚠️ 取决于厂商 |
| 工业 / 边缘 / 隔离网络 | ✅ | ✅（Disconnected Operations） | ✅ |
| GitOps / Azure 集成栈 | ❌ | ✅ | ❌ |

这三种路径不是简单替代关系------它们解决不同问题，匹配不同企业 IT 战略。

八、最终结论

回到核心边界问题：

Windows Server 本身不是 AKS 的运行平台，但这并不意味着 Windows Server 技术栈不能承载 AKS。Azure Stack Hub 和 Azure Local 都证明：当 Windows Server Datacenter 之上叠加 Azure 控制平面、资源管理、生命周期管理和 Azure Arc 能力后，Windows Server 可以成为 Azure 平台形态的一部分，并提供 AKS 服务能力。

因此，真正的边界不是 "Windows Server vs AKS"，而是：

|-----------------------|--------------------------------------------------------------------|
| 不是 | 而是 |
| Windows Server vs AKS | 裸 Windows Server ≠ Azure 平台 |
| 能不能装 K8s？ | 能不能提供 AKS 服务能力？ |
| 是不是软件包？ | 是不是 Azure 平台形态？ |
| Azure Stack Hub 反例 | Azure Stack Hub / Azure Local 都是 Windows Server 技术栈，差异在 Azure 平台叠加 |

更准确的最终表述：

裸 Windows Server 不提供 AKS 服务能力，但基于 Windows Server 构建并叠加 Azure 平台控制面后，可以成为支持 AKS 的 Azure 平台形态。

这就是为什么：

  • 裸 Windows Server = ❌ 不能提供 AKS
  • Azure Stack Hub（= Windows Server + Azure 平台控制面）= ✅ 提供 Kubernetes 服务能力
  • Azure Local（= Microsoft Validated HCI + Windows Server Azure Edition + Azure Arc + Azure Management）= ✅ 提供 AKS

而微软推动 Azure Local + AKS enabled by Azure Arc + Azure Arc 的根本产品逻辑：

不是在 Windows Server 上增加一个 Kubernetes 功能，而是在 Windows Server 技术栈之上，构建企业本地 Azure 平台形态。

AKS 是这种 Azure 平台形态的标准服务之一------而非"装在 Windows Server 上的应用"。

附录：常见误区速查

|--------------------------------------------------------|--------------------------------------------------------------------------|
| 误解 | 事实 |
| Windows Server 不能跑 K8s | ✅ 可以（通过 VM 或 Windows Worker Node） |
| 安装 AKS 需要一台 Windows Server | ❌ AKS 不是软件包 |
| Windows Server Datacenter 不能承载 AKS / Kubernetes 服务 | ✅ Azure Stack Hub 反例证明可以，但需要叠加 Azure 平台控制面 |
| Azure Local AKS 等价于在 Windows Server 上跑 K8s | ❌ Azure Local AKS 是 Azure 平台形态上的云服务能力，与自建 K8s 本质不同 |
| 把 Hyper-V 上的 Linux VM 跑 K8s 当作 AKS | ❌ 那是用户自建的 Kubernetes |
| Azure Stack Hub 的 Kubernetes 服务是装在 Windows Server 上的应用 | ❌ Azure Stack Hub 是 Azure 平台形态的独立延伸 |
| Azure Local AKS 控制面在 Azure 公有云 | ❌ Azure Local AKS 控制面运行在企业 Azure Local 环境内的 VM 中 |
| Azure Local AKS = Azure 公有云 AKS 那种完全托管 / PaaS | ❌ 是 Kubernetes 生命周期管理能力，仍需企业负责 GPU 驱动栈、镜像、Helm Chart 等 |
| Azure Local AKS 在断网时所有功能可用 | ❌ Azure Local AKS 提供 Disconnected Operations 能力（范围受限），具体随版本变化 |
| Azure Local = "Windows Server 装几个组件" | ❌ Azure Local 是经过 Microsoft Validated + OEM 认证 + Azure 控制面集成的 Azure 平台形态 |
| 第三方 K8s 平台可以装在 Windows Server 上 | ❌ 例如 VMware Tanzu 跑 vSphere / 裸机；OpenShift 跑 RHEL；不是 Windows Server 基础平台 |

相关推荐
Cosolar17 小时前
AI Agent 架构原理详解：从一次提问到任务完成的完整闭环
人工智能·后端·架构
Wild_Pointer.17 小时前
高效工具实战指南：Procexp64进程资源管理器
c++·windows
会周易的程序员18 小时前
Libnodave S7 通信库：架构设计与实现解析
linux·c++·物联网·架构·c·s7·工业协议
小小猪的春天18 小时前
团队级 Code Review Skill 实践：4个人、4个AI、1套规则，CR从找bug变成做决策
后端·架构
Geek-Chow18 小时前
Connecting kubectl to a Private EKS Cluster Over an Internal Domain
kubernetes·k8s·aws
码农学院19 小时前
建筑机械行业AI搜索优化技术方案：基于Spring Cloud微服务架构的文件管理与智能化内容推荐系统
人工智能·spring cloud·架构
这是柠檬君19 小时前
Microsoft Activation Scripts（MAS）最新版！
windows·office
xinhuanjieyi20 小时前
cargo在windows系统下编译成exe，用everything搜索路径
windows·everything
Kel20 小时前
Node.js 单线程高并发：从内核中断到 JS 回调的完整技术栈
设计模式·架构·node.js
热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03如何新建文件夹？ 电脑新建文件夹的4种方法04AI科技热点日报 | 2026年07月01日05幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南06【AI前线观察】2026年国产开源大模型全面横评：从 DeepSeek V4 到 Kimi K3，谁才是开发者的最优选择？07国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）08AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路092026 年 AI 大模型 & AI 编程工具实战全总结102026年AI技术突破与产业落地全景：从GPT-5到多模态智能体的新纪元