HTML无函数，硬件访问全靠JavaScript调用浏览器API；如getUserMedia、geolocation、DeviceMotionEvent等，需HTTPS、用户手势触发、权限授权及设备支持，HTML仅作容器或语法糖。
HTML 本身没有“函数”——你写的不是 HTML 函数，而是 JavaScript 调用浏览器 API 访问硬件，HTML 只负责承载和触发。 所有“HTML 控制摄像头/麦克风/定位/Gyroscope”的说法，本质都是 navigator.mediaDevices.getUserMedia()、navigator.geolocation.getCurrentPosition() 这类 JS 接口在起作用，HTML 标签（比如 <video>）只是渲染容器或事件载体。
为什么 <input type="file" accept="image/*" capture="user"> 看起来像“调用摄像头”？
这是 HTML 原生的快捷语法糖，但背后完全依赖浏览器实现，不跨平台、不保证行为一致：
- 仅在部分移动端浏览器生效（Chrome Android、Safari iOS），桌面端基本忽略
capture属性 - 它不返回原始流（
MediaStream），无法做实时处理（如美颜、滤镜、人脸识别） - 触发的是系统相册/相机 App，而非网页内直接获取流，控制粒度极低
- 权限模型仍是 JS 驱动：点击后仍会弹出
Permission denied或被拦截（尤其 HTTP 站点、iframe 嵌套、非用户手势触发）
navigator.mediaDevices.getUserMedia() 怎么真正拿到摄像头画面？
这才是可控、可编程的硬件访问起点。关键不在“怎么写”，而在“怎么不让它失败”：
- 必须运行在
https://或localhost下，HTTP 页面直接拒绝调用，控制台报NotAllowedError: Permission denied - 必须由用户手势触发（如
click、tap），不能在页面加载时自动执行，否则报NotAllowedError: The request is not allowed by the user agent - 要显式声明约束：
{ video: { facingMode: "user" }, audio: false }比{ video: true }更可靠，避免某些设备默认选后置或拒绝无音频请求 - 拿到
MediaStream后，需赋给<video>的srcObject属性（不是src），否则黑屏
button.addEventListener("click", async () => {
try {
const stream = await navigator.mediaDevices.getUserMedia({
video: { facingMode: "user" },
audio: false
});
videoEl.srcObject = stream; // 注意是 srcObject，不是 src
} catch (err) {
console.error("硬件访问失败:", err.name); // 常见：NotAllowedError、NotFoundError
}
});
为什么 DeviceOrientationEvent 在 iOS 上不工作？
iOS Safari 默认禁用陀螺仪和加速度计事件，除非用户明确开启“运动与方向权限”，且网页必须满足两个硬性条件：
立即学习“前端免费学习笔记（深入）”；
- 页面需通过
https提供（HTTP 直接静默失效） - 首次监听前，必须由用户手势触发一次
requestPermission调用（iOS 13+ 强制要求）：
// iOS 专属初始化
if (typeof DeviceMotionEvent !== "undefined" && typeof DeviceMotionEvent.requestPermission === "function") {
document.body.addEventListener("click", async () => {
await DeviceMotionEvent.requestPermission();
window.addEventListener("devicemotion", handleMotion);
}, { once: true });
}
没走这一步，devicemotion 和 deviceorientation 事件在 iOS 上完全不会触发，连监听都注册不上。
硬件访问从来不是“写对标签就通”，而是层层校验：协议、上下文、权限、设备能力、用户交互时机。最容易被忽略的是——所有这些 API 都可能被浏览器策略、系统设置、甚至用户手动关闭权限而彻底切断，且错误信息往往模糊（比如只报 SecurityError 却不说明缺 HTTPS 还是缺手势）。上线前务必在真机、不同浏览器、禁用权限后反复验证 fallback 行为。
