mac系统下通过web bluetooth api向设备写入数据时，存在严格的单次写入长度限制（152字节），超出将导致写入行为异常（如重复触发、无完成回调），而windows无此限制；解决方案是将大数据分片为≤152字节的uint8array片段，按序逐次写入并等待每步完成。
mac系统下通过web bluetooth api向设备写入数据时，存在严格的单次写入长度限制（152字节），超出将导致写入行为异常（如重复触发、无完成回调），而windows无此限制；解决方案是将大数据分片为≤152字节的uint8array片段，按序逐次写入并等待每步完成。
在 macOS 上使用 Chrome 浏览器调用 Web Bluetooth API（例如 characteristic.writeValue()）向蓝牙外设（如您的切割设备）发送指令时，若传输的数据长度超过 152 字节，系统底层会静默截断或触发重试机制——这正是您观察到“命令无限重复执行”且 console.log("Write operation successful") 从未输出的根本原因。该限制是 macOS 蓝牙栈（Core Bluetooth）对 GATT Write Without Response / Write With Response 操作的硬性约束，并非浏览器 Bug，也与设备兼容性无关。
✅ 正确做法：实现分块写入（chunked write）逻辑，确保每批次数据 ≤ 152 字节，并严格串行执行（即前一批 await 完成后再发下一批）：
export async function writeValue(deviceId, serviceId, characteristicId, value) {
const device = getDevice(deviceId);
console.log("START WRITE VALUE.JS", value);
if (!device?.gatt?.connected) {
console.warn("Device not connected, retrying...");
await sleep(1000);
return writeValue(deviceId, serviceId, characteristicId, value);
}
try {
const service = await device.gatt.getPrimaryService("e2088282-4fde-42f9-bb22-6ec3c7ed8f91");
const characteristic = await service.getCharacteristic("6d92661d-f429-4d67-929b-28e7a9780912");
// ? 关键：分块写入，每块最多 152 字节
const CHUNK_SIZE = 152;
const data = new Uint8Array(value);
let offset = 0;
while (offset <p>⚠️ 注意事项：</p>
- 切勿使用 writeValueWithoutResponse：虽然它理论上更快，但在 macOS 上更易因缓冲区问题丢失数据或触发未定义行为；优先使用 writeValue（即 Write With Response）以确保每块写入被设备确认。
- 避免递归重连逻辑嵌套在写入函数内：您原代码中失败后直接递归调用 writeValue，可能造成调用栈溢出或状态混乱。建议将连接管理与数据写入职责分离。
- 校验设备响应（可选进阶）：若设备支持通知（Notify），可在写入后监听对应 characteristic 的 characteristic.addEventListener('characteristicvaluechanged', ...)，确认设备已接收并处理完毕，再执行下一步（如发送“开始切割”指令）。
- Blazor 侧同步保障：在 C# 中调用该 JS 函数时，务必 await 其 Promise 返回，防止 UI 层误判操作已完成。
总结：这不是“Mac 又在犯病”，而是其蓝牙协议栈对 Web API 的明确设计约束。尊重 152 字节边界、主动分片、严格串行、善用响应确认——四步即可彻底解决重复写入问题，让您的切割设备在 macOS 下稳定、精准地执行每一条指令。
