可通过命名导出Meter实例和注册函数封装指标采集逻辑，对外提供标准化可观测性能力；禁止导出内部状态、业务函数及敏感配置，所有采集须经统一入口触发并配合OpenTelemetry Exporter使用。
可以通过 命名导出 + 封装指标采集逻辑 的方式，在不暴露内部实现细节的前提下，对外提供标准化、可复用的可观测性能力。
封装指标定义，只导出 Meter 实例和注册方法
不要直接导出原始计数器或直方图变量，而是将指标创建、标签绑定、采集触发等逻辑封装在私有函数中。对外仅通过命名导出暴露经过预配置的 Meter 实例或注册函数：
- 使用
System.Diagnostics.Metrics.Meter创建专用计量器（如new Meter("MyService.Observability")） - 在模块内部完成
Counter<int></int>、Histogram<double></double>等指标的初始化与维度标签（如 service.name、endpoint）绑定 - 导出一个命名函数（如
exportMetrics），供宿主调用以完成 OpenTelemetry 的 Meter 注册
避免导出敏感状态或业务逻辑变量
命名导出仅限可观测性接口本身，禁止导出以下内容：
- 内部缓存对象、上下文管理器、未封装的 ActivitySource 实例
- 含业务规则的计算函数（如
calculateRetryDelay） - 硬编码的连接字符串、密钥、路径等配置值
所有指标采集行为应通过统一入口（如中间件、装饰器、拦截器）触发，而非由外部直接调用底层统计方法。
配合 OpenTelemetry Exporter 使用命名导出的 Meter
导出的 Meter 实例需与 OpenTelemetry SDK 配合才能生效：
- 在宿主服务启动时，调用你导出的
exportMetrics()函数，将该 Meter 添加到全局MeterProvider - 搭配
OpenTelemetry.Exporter.Console或OpenTelemetry.Exporter.Prometheus输出指标 - 确保导出包不含
Microsoft.Extensions.DependencyInjection等宿主强依赖，保持轻量与解耦
示例结构（.NET + JS 混合语境类比）
虽然 .NET 本身不用 export 关键字，但若构建跨语言可观测 SDK（如为 Blazor WebAssembly 提供 JS 封装层），可参考如下 JS 模块设计：
// observability.js
const meter = new Meter('my-app');
const requestCounter = meter.createCounter('http.requests.total');
const latencyHistogram = meter.createHistogram('http.request.duration');
// ✅ 安全导出：仅暴露注册行为
export function registerWithOpenTelemetry(provider) {
provider.addMeter(meter);
}
// ✅ 安全导出：暴露指标上报接口，不暴露内部构造
export function recordHttpRequest(method, statusCode, durationMs) {
requestCounter.add(1, { method, status_code: statusCode });
latencyHistogram.record(durationMs, { method, status_code: statusCode });
}
这样调用方只需 import { registerWithOpenTelemetry, recordHttpRequest }，完全无需了解指标如何创建、标签如何绑定、数据如何序列化。
