WebRTC 音频处理链路通常先对麦克风采集的信号做噪声抑制，然后将估计出的信噪比送到增益控制环节。平滑时间常数控制的是信噪比估值的变化速度，如果这个值设置得过大，输出会紧跟瞬时噪声，容易出现听感上的抖动；设置得较小，降噪会更稳定但对突发的语音起始会有轻微延迟。浏览器若通过媒体轨道约束暴露该参数，开发者就能在采集阶段对不同的通话场景进行微调。TypeScript 标准库中的 MediaTrackConstraints 目前并未收录这个实验性字段，直接书写带该属性的约束对象会得到类型错误。
这里的关键并不是让编译器强制绕开检查，而是在扩展类型的同时保留媒体约束本身的表达力。接下来分别从接口合并、约束类型设计以及运行时兼容性三个层面说明具体做法。
为什么标准库会缺少这个约束属性
TypeScript 的 DOM 类型主要来自 lib.dom.d.ts，它覆盖了大多数稳定后的 Web 标准，但对于浏览器厂商正在试验阶段的能力，往往不会立即更新。WebRTC 摄像机与麦克风约束就是典型例子，signalToNoiseRatioSmoothingTimeConstant 既可能出现在 Chromium 系浏览器的 getSupportedConstraints 结果中，也可能使用 goog 前缀暴露，这使得标准类型定义很难统一。因此当开发者按照浏览器提示直接在约束对象里写这个字段时，编译器会因为 MediaTrackConstraintSet 中没有该成员而报错。
另一个原因是媒体约束采用字典继承结构。MediaTrackConstraints 继承自 MediaTrackConstraintSet，音频与视频共享同一套基础约束。如果只顾着把类型断言到 any，虽然能立刻绕开编译错误，但后续调用方无法获得该属性是否存在的提示，重构时容易漏改。更合理的做法是扩展全局接口，让类型系统承认这个实验字段，并且保留其他标准约束的检查能力。
通过接口合并补齐 MediaTrackConstraints 类型
要补齐类型，可以在项目根目录放置一个 d.ts 文件，比如 webrtc-snr-smoothing.d.ts，然后利用 TypeScript 的全局接口合并特性。MediaTrackConstraintSet 是全局接口，只要在 declare global 块里再次声明同名接口，新增的成员就会合并到标准类型中。下面是具体的声明：
declare global {
interface MediaTrackConstraintSet {
signalToNoiseRatioSmoothingTimeConstant?: ConstrainDouble;
googSignalToNoiseRatioSmoothingTimeConstant?: ConstrainDouble;
}
}
export {};
这里把属性类型设为 ConstrainDouble，而不是简单的 number。原因是媒体约束框架允许开发者在普通数值和范围对象之间切换。ConstrainDouble 在标准库中对应 number 与 ConstrainDoubleRange 的联合，后者可以包含 min、max、exact、ideal 等字段。用这个类型声明后，既可以传入 0.5，也可以传入一个带有 ideal 值的对象，表达更完整。
由于该文件只要出现 export 或 import 表达式，就会被视为模块，所以末尾的 export {} 能确保 declare global 生效。如果你的 TypeScript 配置不支持全局 DOM 类型，还需要确认 tsconfig 中没有通过 lib 选项把 DOM 排除。声明添加完成后，原先的编译错误会消失，而且不会再影响 echoCancellation、noiseSuppression 等标准字段的类型检查。
构建更安全的平滑时间常数封装
ConstrainDouble 解决了约束结构层面的类型问题，但并不能限制平滑时间常数的具体取值范围。在浏览器实现中，这个值通常要求在 0 到 1 之间，越接近 0 平滑效果越强，延迟也可能越大。类型系统本身很难直接表达连续数值范围，即便使用品牌类型或模板字面量，也无法覆盖所有合法值。因此更实用的方式是把范围校验下沉到运行时，让类型声明保持简单，同时提供统一构造函数。
下面是一个封装示例，它接收平滑时间常数，在构造 MediaStreamConstraints 之前先做校验，避免把非法值传到 getUserMedia 时被浏览器静默忽略或抛出不明确的错误：
function createAudioConstraint(snrSmoothing: number): MediaStreamConstraints {
if (!Number.isFinite(snrSmoothing)) {
throw new RangeError('signalToNoiseRatioSmoothingTimeConstant must be finite');
}
if (snrSmoothing < 0 || snrSmoothing > 1) {
throw new RangeError('signalToNoiseRatioSmoothingTimeConstant must be between 0 and 1');
}
return {
audio: {
echoCancellation: true,
noiseSuppression: true,
signalToNoiseRatioSmoothingTimeConstant: snrSmoothing
}
};
}
这个函数返回的是 MediaStreamConstraints，而不是 MediaTrackConstraints，因为 getUserMedia 的顶层约束对象包含 audio 或 video 两个媒体轨道。把已经声明的属性直接放进 audio 对象中，TypeScript 可以正常推导。调用方只需要传入 0 到 1 之间的数值，其他复杂约束仍然可以继续追加，不必因为扩展声明而改变既有代码风格。
兼容性判断与降级策略
即便类型声明通过了，不同浏览器的支持情况也未必一致。接入前最好用 getSupportedConstraints 判断当前环境是否识别该字段。由于属性可能以标准名或 goog 前缀形式出现，可以写一个辅助函数同时检查两种命名：
function supportsSnrSmoothing(): boolean {
if (!('mediaDevices' in navigator)) {
return false;
}
if (!navigator.mediaDevices.getSupportedConstraints) {
return false;
}
const supported = navigator.mediaDevices.getSupportedConstraints();
return 'signalToNoiseRatioSmoothingTimeConstant' in supported ||
'googSignalToNoiseRatioSmoothingTimeConstant' in supported;
}
如果不支持，就不应把该约束传给 getUserMedia，否则部分浏览器可能直接拒绝整个请求。降级方案可以保留现有的降噪参数，只去掉平滑时间常数；或者继续使用 goog 前缀版本做渐进增强。真正启动采集后，还可以通过 track.getSettings 读取最终生效的设置，用 Record 类型做一次安全读取，确认运行时实际选择的是哪个字段。
综合来看，为媒体轨道信噪比平滑时间常数定义 TypeScript 类型并不复杂，复杂的是如何让它与 WebRTC 实验性 API 的演进保持同步。通过全局接口合并保留标准约束检查，通过范围校验函数限制非法输入，再配合特性检测实现降级，能够在类型安全、代码可维护性和真实浏览器兼容性之间取得平衡。
TypeScriptMediaTrackConstraints平滑时间常数修改时间：2026-10-05 21:02:38