首页
/ Playwright ElementHandle 完全解析：从创建、动作管道到弃用迁移的 API 参考

Playwright ElementHandle 完全解析：从创建、动作管道到弃用迁移的 API 参考

2026-09-06 09:08:20作者：侯霆垣
playwright
Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
项目地址：https://gitcode.com/GitHub_Trending/pl/playwright

ElementHandle 是 Playwright 中代表页面内一个具体 DOM 元素的句柄类（自 v1.8 起提供），由 class-elementhandle.md 完整定义。它让你能直接对某个已解析出的元素执行点击、填充、截图、派发事件等操作，也是理解 Playwright 自动等待（actionability）机制的最佳切入点。读完后，你将掌握 ElementHandle 的创建与生命周期语义、全部方法的参数细节、底层动作重试管道的源码级实现，以及何时应该改用 Locator 的迁移策略。

1. 定位与创建：一个指向"特定节点"的句柄

ElementHandle 继承自 JSHandle，表示页面内一个已经解析出来的 DOM 元素。创建方式主要有 Page.$ / Page.querySelector 及其等价物：

const hrefElement = await page.$('a');
await hrefElement.click();

ElementHandle hrefElement = page.querySelector("a");
hrefElement.click();

href_element = await page.query_selector("a")
await href_element.click()

href_element = page.query_selector("a")
href_element.click()

var handle = await page.QuerySelectorAsync("a");
await handle.ClickAsync();

文档对该类开宗明义地标了一个 Discouraged（不推荐） 警告：优先使用 Locator 对象和 web-first assertions。这不是随口一提——下文会解释两种对象在语义上的本质差异，以及这个建议如何落到源码的行为上。

生命周期语义（来自文档的三条关键约束）：

  1. ElementHandle 会阻止底层 DOM 元素被垃圾回收，除非你显式调用 JSHandle.dispose 释放句柄；
  2. 当元素所在的 frame 发生导航时，ElementHandle 会被自动 dispose；
  3. ElementHandle 实例可以作为 Page.evalOnSelector 和 Page.evaluate 的参数传入。

从客户端源码可以看到，每个 ElementHandle 都持有一个所属 Frame 的引用，这正是"随 frame 导航而失效"语义的来源：

// packages/playwright-core/src/client/elementHandle.ts
export class ElementHandle<T extends Node = Node> extends JSHandle<T> implements api.ElementHandle {
  private _frame: Frame;
  readonly _elementChannel: channels.ElementHandleChannel;

  constructor(parent: ChannelOwner, type: string, guid: string, initializer: channels.JSHandleInitializer) {
    super(parent, type, guid, initializer);
    this._frame = parent as Frame;
    this._elementChannel = this._channel as channels.ElementHandleChannel;
  }

（见 packages/playwright-core/src/client/elementHandle.ts#L38-L54）所有带等待语义的方法都通过 this._frame._timeout(options) 计算超时，即 ElementHandle 的默认超时继承自其所属 Frame 的超时配置，而不是 Page 级配置——这是阅读 API 签名时容易忽略的一点。

2. ElementHandle 与 Locator 的本质区别

文档用一组对照示例讲清了核心差异：

ElementHandle 指向页面上的某个特定 DOM 元素；而 Locator 捕获的是如何找到元素的逻辑。

ElementHandle 版本——handle 永远指向最初那个 DOM 节点，即使它的文本被改写、甚至被 React 重新渲染成完全不同的组件：

const handle = await page.$('text=Submit');
// ...
await handle.hover();
await handle.click();

Locator 版本——每次使用时都用选择器重新定位一个"最新"的 DOM 元素。下面这个片段中，底层元素实际会被定位两次：

const locator = page.getByText('Submit');
// ...
await locator.hover();
await locator.click();

同一行为在 Java / Python / .NET 中一一对应（page.getByText("Submit") / page.get_by_text("Submit") / page.GetByText("Submit")，详见 class-elementhandle.md 原文的四语言示例）。

实践结论：SPA、React/Vue 等框架下 DOM 节点会被频繁替换，ElementHandle 这种"钉死节点"的语义天然容易在二次操作时失效；Locator 的"延迟重新解析"正好消解了这类问题。因此文档对 click、fill、hover、check、screenshot 等几乎每个动作方法都加了 discouraged 注释，指向对应的 Locator.* 方法。

3. 动作类方法与 actionability 检查

ElementHandle 的动作方法（click / dblclick / hover / tap / check / uncheck / setChecked / fill / selectOption / selectText / press / type）共享同一套执行语义。以 click 为例，文档给出的步骤是：

  1. 等待元素通过 actionability 检查，除非设置了 force；
  2. 必要时把元素滚动进视口；
  3. 用 Page.mouse 点击元素中心或指定的 position；
  4. 等待由点击触发的导航成功或失败，除非设置了 noWaitAfter。

如果元素在执行过程中从 DOM 中脱离，方法抛错；全部步骤未在 timeout 内完成则抛出 TimeoutError（传 0 可禁用超时）。

各方法的常用参数（均自 v1.8 起，除特别注明）：

方法 关键选项 说明
click button、clickCount、delay、position、modifiers、force、scroll（v1.62）、noWaitAfter、timeout、signal、trial（v1.11）、steps（v1.57） 最完整的指针动作，steps 控制鼠标移动插值步数
dblclick 同上（不含 clickCount、含 trial/steps） 派发两次 click 事件加一次 dblclick 事件
hover position、modifiers、force、scroll（v1.62）、timeout、trial（v1.11） 悬停在元素中心或指定偏移处
tap position、modifiers、force、scroll（v1.62）、trial（v1.11） 使用 Page.touchscreen；要求浏览器上下文 hasTouch: true
check / uncheck position、force、scroll（v1.62）、timeout、trial（v1.11） 先校验目标是 checkbox/radio，已处于目标状态则立即返回
setChecked（v1.15） checked、force、scroll（v1.62）、position、timeout、trial 按 checked 参数走 check 或 uncheck 路径
fill value、force（v1.13）、timeout 聚焦后整体填充并触发 input 事件；空字符串可清空；<label> 内的元素会转填其关联控件
selectOption values、force（v1.13）、timeout 匹配 value 或 label，可多选；完成后触发一次 change 和 input 事件
selectText force（v1.13）、timeout 聚焦并全选文本内容
press key、delay（keydown/keyup 间隔，默认 0）、timeout 聚焦后按键，支持 Control+Shift+T 组合键
type（已弃用） text、delay 逐字符派发 keydown/keypress/input/keyup；官方建议改用 Locator.fill 或 Locator.pressSequentially

check 的执行步骤比 click 多两个状态校验：执行前确认元素是 checkbox/radio（否则抛错）、点击后确认状态确实变为 checked（否则抛错）；uncheck 与之对称。selectOption 还支持按 { label }、{ value }、{ index }（Python 的 label=/value=/index= 关键字参数，C# 的 SelectOptionValue）三种方式描述选项，完整多语言示例见原文档 class-elementhandle.md#L831-L925。

3.1 源码视角：动作不是"点一次"，而是一条重试管道

文档中"等待 actionability 检查"这句话说起来简单，在 packages/playwright-core/src/server/dom.ts 中却是一套完整的重试状态机。服务端 ElementHandle 类的指针动作走 _retryAction → _retryPointerAction → _performPointerAction 三层（见 packages/playwright-core/src/server/dom.ts#L317-L499）：

  1. 渐进式重试间隔：重试等待时间是 [0, 20, 100, 100, 500]ms，即第 2、3、4 次重试分别等 20/100/100ms，之后每次等 500ms，直到超时预算耗尽；
  2. 失败原因驱动重试：error:notvisible（不可见）、error:notinviewport（在视口外）、error:optionsnotfound/error:optionnotenabled（select 选项未就绪）、hitTargetDescription（有遮挡元素拦截指针事件）等结果都会触发继续重试；而设置了 force 时这些可恢复错误会直接升级为 NonRecoverableDOMError 抛出；
  3. 多策略滚动：为了对抗 position: sticky 等遮挡，滚动策略会在 undefined（协议滚动）、end/end、center/center、start/start 四种对齐方式间轮换；
  4. 状态校验：非 force 模式下，点击类动作会校验 visible, enabled and stable 三个状态，hover/tap 类只校验 visible, stable，校验由页面内的 InjectedScript 完成；
  5. 命中目标拦截器：动作前会安装 hit target interceptor，确保点击确实落在目标元素上而不是被弹窗/遮罩截胡。

这解释了文档中两条经验的底层逻辑：force: true 会跳过可见性/命中检查（适合对虚拟列表等"点不中"的场景），trial: true 则只跑校验管道不真正执行动作（适合预检）；而 scroll: 'none' 会完全跳过滚动步骤。

4. 读取与查询类方法

ElementHandle 上的一组轻量读方法（客户端侧均使用 kNoTimeout 即无框架级超时，直接在服务端取值）：

方法 返回 说明
boundingBox {x, y, width, height} 或 null 元素不可见时返回 null
getAttribute(name) string | null 属性值
inputValue（v1.13） string <input>/<textarea>/<select> 的 value；非表单元素抛错，但 <label> 内的元素会转读其关联控件。注意其 timeout 选项已被标注忽略（取值立即返回）
textContent string | null node.textContent
innerText string element.innerText
innerHTML string element.innerHTML
isChecked boolean 非 checkbox/radio 时抛错
isEnabled / isDisabled boolean enabled 状态及其取反
isEditable boolean editable 状态
isVisible / isHidden boolean visible 状态及其取反
ownerFrame Frame | null 返回包含该元素的 frame
contentFrame Frame | null 仅当句柄引用的是 iframe 节点时返回其内容 frame

boundingBox 的三个易错点（全部来自文档原文）：

  1. 坐标系相对主 frame 视口（通常即浏览器窗口），滚动会影响返回值，x/y 可能为负——这一点与 Element.getBoundingClientRect 行为一致；
  2. 子 frame 中元素的 box 也是相对主 frame 返回的，这与 getBoundingClientRect（相对自身 frame）不同；
  3. 页面静态时可以安全地用 box 坐标做输入。示例：点击元素中心。
const box = await elementHandle.boundingBox();
await page.mouse.click(box.x + box.width / 2, box.y + box.height / 2);

子树查询（同样被建议改用 Page.locator）：

  • querySelector(selector)（JS 别名 $）：在句柄子树中找第一个匹配元素，无匹配返回 null；
  • querySelectorAll(selector)（JS 别名 $$）：找全部匹配元素，无匹配返回空数组。

服务端实现上这些"读取"方法有一个统一技巧——把选择器替换成 :scope，以句柄自身为作用域根节点执行查询（见 packages/playwright-core/src/server/dom.ts#L200-L222）：

async getAttribute(progress: Progress, name: string): Promise<string | null> {
  return this._frame.getAttribute(progress, ':scope', name, {}, this);
}
async dispatchEvent(progress: Progress, type: string, eventInit: Object = {}) {
  return this._frame.dispatchEvent(progress, ':scope', type, eventInit, {}, this);
}

4.1 $eval 与 $$eval：在子树内直接求值

evalOnSelector(selector, expression, arg)（JS 别名 $eval，v1.9 起）在句柄子树中找到匹配选择器的第一个元素并作为表达式第一参数传入；无匹配元素时抛错。若表达式返回 Promise，会等待其 resolve。

const tweetHandle = await page.$('.tweet');
expect(await tweetHandle.$eval('.like', node => node.innerText)).toBe('100');
expect(await tweetHandle.$eval('.retweets', node => node.innerText)).toBe('10');

evalOnSelectorAll（JS 别名 $$eval）则把所有匹配元素组成的数组作为第一参数传入：

<div class="feed">
  <div class="tweet">Hello!</div>
  <div class="tweet">Hi!</div>
</div>

const feedHandle = await page.$('.feed');
expect(await feedHandle.$$eval('.tweet', nodes =>
  nodes.map(n => n.innerText))).toEqual(['Hello!', 'Hi!']);

两者的 selector、expression（支持字符串或函数，字符串形态可用 arg 传参）参数一致。文档对这两个方法的弃用建议措辞更直白：$eval 不等待 actionability，容易写出 flaky 测试，推荐改用 Locator.evaluate、Locator 辅助方法或 web-first assertions。客户端实现见 packages/playwright-core/src/client/elementHandle.ts#L219-L227——表达式被序列化为字符串 + isFunction 标志随 channel 发送。

5. dispatchEvent 与 press 的细节

5.1 dispatchEvent：绕过可见性的事件注入

dispatchEvent(type, eventInit) 在元素上派发指定 DOM 事件，与元素可见状态无关。对 click 类型，等价于调用 element.click()：

await elementHandle.dispatchEvent('click');

底层行为（文档原文）：按 type 创建事件实例、用 eventInit 属性初始化、然后派发；事件默认 composed、cancelable 且冒泡。由于 eventInit 是事件类型特定的，完整属性列表需对照对应事件构造器（DeviceMotionEvent、DragEvent、Event、FocusEvent、KeyboardEvent、MouseEvent、PointerEvent、TouchEvent、WheelEvent）。

它还有一个高阶用法——在事件属性里传入活的 JSHandle 对象（如 DataTransfer，注意只能在 Chromium 和 Firefox 中创建）：

// Note you can only create DataTransfer in Chromium and Firefox
const dataTransfer = await page.evaluateHandle(() => new DataTransfer());
await elementHandle.dispatchEvent('dragstart', { dataTransfer });

5.2 press：键名体系

press(key) 先聚焦元素，再依次执行 Keyboard.down / Keyboard.up。key 可以是：

  • 标准 keyboardEvent.key 值：F1-F12、Digit0-Digit9、KeyA-KeyZ、Backquote、Minus、Equal、Backslash、Backspace、Tab、Delete、Escape、ArrowDown、End、Enter、Home、Insert、PageDown、PageUp、ArrowRight、ArrowUp 等；
  • 单个字符（区分大小写，a 与 A 产生不同文本；按住 Shift 会输出对应大写文本）；
  • 修饰组合：Shift、Control、Alt、Meta、ShiftLeft、ControlOrMeta，以及 Control+o、Control++、Control+Shift+T 这类快捷键形式——修饰键会在后续按键按住期间保持按下。

delay（默认 0ms）控制 keydown 与 keyup 之间的间隔。

6. 状态等待：waitForElementState 与 waitForSelector

waitForElementState(state) 在元素满足指定状态时返回，状态即 actionability 的六种检查：

  • "visible"：元素可见；
  • "hidden"：元素不可见或已脱离 DOM——等待 hidden 时元素脱离不会抛错；
  • "stable"：可见且稳定（连续两帧位置不变）；
  • "enabled"：可用；
  • "disabled"：不可用；
  • "editable"：可编辑。

除 "hidden" 外，等待过程中元素脱离会抛错；超过 timeout 未完成也会抛错。

waitForSelector(selector, options) 在句柄子树内等待选择器满足 state（attached / detached / visible / hidden），等待 hidden 或 detached 时返回 null；strict（v1.15 起）开启严格模式。文档明确警告：此方法不跨导航工作，需要跨导航请使用 Page.waitForSelector。

await page.setContent(`<div><span></span></div>`);
const div = await page.$('div');
// 在 div 范围内等待 'span' 出现
const span = await div.waitForSelector('span', { state: 'attached' });

page.setContent("<div><span></span></div>");
ElementHandle div = page.querySelector("div");
ElementHandle span = div.waitForSelector("span", new ElementHandle.WaitForSelectorOptions()
  .setState(WaitForSelectorState.ATTACHED));

await page.set_content("<div><span></span></div>")
div = await page.query_selector("div")
span = await div.wait_for_selector("span", state="attached")

await page.SetContentAsync("<div><span></span></div>");
var div = await page.QuerySelectorAsync("div");
var span = await div.WaitForSelectorAsync("span", WaitForSelectorState.Attached);

（C# 原文档示例中写的是 page.WaitForSelectorAsync，与"相对 div 等待"的语义不符；上文按方法签名 ElementHandle.waitForSelector 调整为实例调用。）

scrollIntoViewIfNeeded（建议改用 Locator.scrollIntoViewIfNeeded）：等待 actionability 检查后尝试滚动，除非元素已按 IntersectionObserver 的 ratio 定义完全可见；当句柄不指向连接到 Document 或 ShadowRoot 的节点时抛错。

7. setInputFiles 与 screenshot：两个带"隐藏机制"的方法

7.1 setInputFiles：路径、目录与 50MB 上限

将 file input 的值设置为文件路径或文件对象；相对路径相对当前工作目录解析；空数组清空已选文件；[webkitdirectory] 输入只支持单个目录路径。期望句柄指向 <input> 元素，但 <label> 内的元素会转作用于其关联控件。

客户端 convertInputFiles（packages/playwright-core/src/client/elementHandle.ts#L282-L322）揭示了两个文档未细说的约束：

  • 路径与 buffer 不能混传：items.some(item => typeof item === 'string') 且存在非字符串项时直接抛 'File paths cannot be mixed with buffers'；目录路径也只允许出现一个（'Multiple directories are not supported'）；
  • buffer 总大小超过 50MB 报错：'Cannot set buffer larger than 50Mb, please write it to a file and pass its path instead.'；
  • 远程连接场景（context._connection.isRemote()）下，本地路径会被改写为临时文件流（createTempFiles）再传输，目录会打包为 directoryStream——所以"传路径"在远程模式下并非直接把路径字符串发给浏览器。

7.2 screenshot：裁剪到元素 + 类型推断

screenshot 截取裁剪到该元素尺寸与位置的页面截图：被其他元素覆盖的部分不会真正出现在截图里；可滚动容器只截取当前滚动到的内容。方法会先等待 actionability 检查并滚动进视口，元素脱离 DOM 则抛错，返回截图 Buffer。

关键选项（按文档标注的版本）：

  • 通用截图选项列表（%%-screenshot-options-common-list-v1.8-%%，v1.8 起）；
  • maskColor（v1.34 起）：遮罩区域的颜色；
  • style（v1.41 起）：截取前注入的 CSS；
  • timeout、signal。

客户端 screenshot 实现（packages/playwright-core/src/client/elementHandle.ts#L191-L208）补充了两点：mask 接受 Locator[]（被映射为 {frame, selector} 对下发）；当只传了 path 未传 type 时，determineScreenshotType 会根据文件扩展名推断 png/jpeg/webp，并顺带写入磁盘后仍返回 Buffer。测试仓库中的 tests/library/screenshot.spec.ts 对 page.$('div').screenshot() 的裁剪行为（含被遮挡、mask 遮罩等）有大量回归用例。

8. 完整 API 清单速查

以下按 class-elementhandle.md 的方法顺序整理，标注了弃用（discouraged）与替代建议：

方法 起始版本 状态 / 替代建议
boundingBox v1.8 保留
click v1.8 弃用 → Locator.click
dblclick v1.8 弃用 → Locator.dblclick
tap v1.8 弃用 → Locator.tap；需 hasTouch
hover v1.8 弃用 → Locator.hover
check / uncheck v1.8 弃用 → Locator.check / Locator.uncheck
setChecked v1.15 弃用 → Locator.setChecked
fill v1.8 弃用 → Locator.fill
type v1.8 弃用 → Locator.fill / Locator.pressSequentially
press v1.8 弃用 → Locator.press
selectOption v1.8 弃用 → Locator.selectOption
selectText v1.8 弃用 → Locator.selectText
setInputFiles v1.8 弃用 → Locator.setInputFiles
screenshot v1.8 弃用 → Locator.screenshot
scrollIntoViewIfNeeded v1.8 弃用 → Locator.scrollIntoViewIfNeeded
dispatchEvent v1.8 弃用 → Locator.dispatchEvent
evalOnSelector（$eval） v1.9 弃用 → Locator.evaluate / web-first assertions
evalOnSelectorAll（$$eval） v1.9 弃用 → Locator.evaluateAll 等
querySelector（$）/ querySelectorAll（$$） v1.9 弃用 → Page.locator
waitForSelector v1.8 弃用 → Locator.waitFor / web 断言
waitForElementState v1.8 保留
textContent / innerText / innerHTML v1.8 弃用 → 对应 Locator.*
inputValue v1.13 弃用 → Locator.inputValue
isChecked / isDisabled / isEditable / isEnabled / isHidden / isVisible v1.8 弃用 → 对应 Locator.*
getAttribute v1.8 弃用 → Locator.getAttribute
focus v1.8 弃用 → Locator.focus
ownerFrame / contentFrame v1.8 保留

注意版本演进留下的痕迹：scroll 选项统一在 v1.62 才补齐到 check/click/dblclick/hover/tap/uncheck；noWaitAfter 在多数方法上已被移除（%%-input-no-wait-after-removed-%%），即 Playwright 现在总是等待动作引发的导航/信号；signal（AbortSignal）为 JS 侧较新的可取消能力，各方法签名中未标注起始版本。

9. 源码架构与测试印证

从源码结构看，ElementHandle 采用典型的三层分发架构：

由于这套执行路径在 playwright-core 的框架无关层，行为对 Chromium、Firefox、WebKit 三种引擎一致（Firefox 的整数坐标修正见 dom.ts#L280-L293 的注释）——这是 Playwright 单 API 驱动多引擎的核心保证之一。

测试侧，ElementHandle（JS 的 page.$）被用作大量回归测试的基础工具，例如：

10. 使用建议小结

  1. 新代码默认写 Locator：page.getByText / page.locator + expect(...).toBeVisible() 等 web-first 断言，规避"钉死节点"的时效性问题（这正是文档顶部警告的意图）；
  2. 必须持有具体节点时使用 ElementHandle：需要 boundingBox 做坐标级操作、contentFrame 钻取 iframe、dispatchEvent 注入合成事件（如 DataTransfer 拖拽）、或把元素作为 evaluate 参数传入时；
  3. 理解超时来源：动作方法超时取自已属 Frame 的超时设置（客户端 this._frame._timeout(options)），读取类方法则不受框架超时约束；
  4. force 与 trial 是调试开关：force 跳过可见性/命中检查（对应源码中 NonRecoverableDOMError 分支），trial 只校验不执行；
  5. 迁移对照：按下文第 8 节速查表逐项替换为 Locator.* 等价方法，$eval/$$eval 迁移到 Locator.evaluate/Locator.evaluateAll。

参考

playwright
Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
项目地址：https://gitcode.com/GitHub_Trending/pl/playwright
登录后查看全文

相关内容推荐

1 Playwright Handles：跨进程页面对象引用机制与实战详解2 Playwright FileChooser API 深度解析：跨浏览器文件上传测试的事件驱动模式3 Playwright 官方迁移指南：从 Puppeteer 切换到 Playwright 的 API 对照、逐行改写与最佳实践4 Puppeteer ElementHandle.dragAndDrop() 详解：废弃拖放 API 的签名、前置条件、事件机制与 drop() 迁移路径5 Puppeteer ElementHandle.dragEnter() 深度解析：已废弃的底层拖放 API 与新拖放体系6 Playwright Frame 类完全指南：掌握页面 iframe 树、定位、求值与导航的核心 API7 Puppeteer ElementHandle.drop 详解：把元素拖拽放到目标位置的正确姿势与源码剖析8 Playwright Library 架构深解：Client、Server 与 Dispatcher 的三层协议架构9 Playwright-dotnet 内存泄漏问题分析与解决方案10 Playwright Evaluate 深入指南：跨环境执行 JavaScript、传递参数与 Init Scripts 原理剖析
热门项目推荐
相关项目推荐

热门内容推荐

1 编程实践项目探索指南：从零构建技术能力体系2 技术解构式学习：从0到1构建你的编程知识体系3 构建自己的技术世界：build-your-own-x项目的实践探索指南4 解锁编程技能的实践之旅：从零构建你的技术世界5 技术实践探索：从零开始构建核心系统的实践指南6 亲手锻造技术引擎：从0到1构建核心系统的实践指南

最新内容推荐

Puppeteer BrowserLauncher.launch() 源码级解析：浏览器进程、协议连接与临时 Profile 的完整启动链路Supabase React 19 组件实战：ref 作为普通 Props 与 use() 替代 useContext() 的迁移指南Storybook Web Components 文档指南：基于 custom-elements.json 自动生成 Props 表格与组件文档Orca Skill Sharing 管理指南：访问模型、吊销删除、保留契约与事故恢复VS Code 开发容器实战：在 Docker 容器中构建、运行并调试 Code - OSSlearn-claude-code s11 背景任务：run_in_background 异步执行与 Agent Loop 结果回收机制CPython 扩展模块定义指南：PyModExport 导出钩子、PyInit 初始化函数与多阶段初始化Protocol Buffers upb Arena 融合与单向引用：锁-free 生命周期协同设计与源码解析Playwright CI 实战指南：在持续集成环境中稳定运行浏览器自动化测试Traefik Consul Provider 实战：用 Consul KV 存储实现路由配置的自动发现与热更新

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件，TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件，使 PyTorch 框架能够直接调用昇腾 NPU，为开发者提供昇腾 AI 处理器的超强算力。
Python
854
1.34 K
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库，实现网络在NPU上加速计算。
C++
1.12 K
2.73 K
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
528
589
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库，实现网络在NPU上加速计算。
C++
907
1.83 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent，它能够将大语言模型的强大能力，通过你日常使用的各类通讯应用，直接延伸至你的指尖。
Python
3.56 K
1.01 K
cann-learning-hubcann-learning-hub
CANN 学习中心仓，支持在线互动运行、边学边练，提供教程、示例与优化方案，一站式助力昇腾开发者快速上手。
Jupyter Notebook
994
510
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
1.34 K
1.45 K
docsdocs
暂无描述
Markdown
894
5.79 K
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
213
313