MongoDB聚合管道是处理数据的一组顺序阶段，每个阶段对文档做筛选、分组、投影或连接等转换。如果开发者希望在聚合计算中把当前客户端连接URI也作为维度或过滤条件，很容易去文档里找一个类似$whatsmyuri的表达式。事实上，MongoDB服务器端并没有内置这样的管道操作符。理解这种需求为何无法直接在管道中实现，需要先看清聚合框架的执行边界。
聚合管道中为什么没有$whatsmyuri操作符
聚合管道运行在数据库服务器进程内部，也就是说不管客户端使用什么驱动、从哪台机器发起请求，管道阶段看到的都只是经过解析后的查询计划和数据流。MongoDB为表达式提供的系统变量只有$$NOW、$$ROOT、$$CURRENT以及若干时间、聚合累计变量，它们全部属于服务器端上下文。客户端连接URI包含主机名、端口、认证数据库、用户名甚至密码等敏感信息，这些内容由驱动或mongosh在连接建立后保存在客户端内存中，并不会附着到文档或系统变量上。因此，在官方文档中搜索$whatsmyuri不会得到任何结果，也不存在所谓客户端URI聚合管道表达式。
如果强行在$project或$addFields阶段使用$whatsmyuri，MongoDB会直接抛出无法识别表达式的错误，因为解析器只认可注册过的操作符。下面这个例子在执行时会失败，错误信息通常包含 Unrecognized expression 字样。
db.collection.aggregate([
{ $project: { uri: "$whatsmyuri" } }
])
// 报错: Unrecognized expression '$whatsmyuri'
从安全角度看，这种隔离是合理的。如果任意只读权限的用户都能通过聚合管道读取客户端连接串，攻击者可能借助一个普通查询就拿到内网地址、认证库或弱口令信息。MongoDB服务端只会在审计日志、连接日志以及currentOp输出中记录有限元数据，比如客户端IP和端口，而不会暴露完整URI。把连接信息限制在驱动层和应用层，既保护了凭证，也让聚合管道的输入输出契约保持清晰。
如何把客户端URI传入聚合管道参与计算
既然管道内部无法读取连接URI，正确做法是在发起聚合请求之前由客户端把URI作为字符串变量传进去。MongoDB聚合框架支持在管道阶段使用$literal表达式，它能把一个外部值原样写入每个文档。比如在Node.js驱动中，可以先定义连接字符串，再把它放进$set阶段，这样每一篇经过聚合的文档都会携带同一个连接URI字段。
const { MongoClient } = require('mongodb');
const uri = 'mongodb://user:pass@127.0.0.1:27017/test?authSource=admin';
const client = new MongoClient(uri);
async function run() {
await client.connect();
const db = client.db('test');
const pipeline = [
{ $set: { connectionURI: { $literal: uri } } },
{ $group: { _id: "$connectionURI", count: { $sum: 1 } } }
];
const result = await db.collection('orders').aggregate(pipeline).toArray();
console.log(result);
}
run();
如果只需要URI中的某一部分，例如主机名或认证库，建议在应用层完成解析，再把需要的字段作为参数传入管道。比如用Node.js的URL对象提取host和pathname，然后分别通过$literal注入。这比在管道里处理字符串拼接更可靠，也能减少聚合服务器的计算负担。需要注意不要把密码原样带进聚合结果，尤其是结果可能需要返回给前端时。
在mongosh中排查当前客户端连接信息时，可以借助db.getMongo()._uri查看当前连接字符串。下面的命令会打印出shell正在使用的完整URI，适合在交互式环境里快速确认连接指向。
// mongosh 中打印当前连接URI const connStr = db.getMongo()._uri; print(connStr);
不过这个_uri属性是mongosh内部实现细节，不同版本可能有差异，正式的应用代码应当使用驱动暴露的配置对象。关键在于理解一个事实：URI从客户端传入管道是可行路径，而不是反过来从管道去抓取客户端信息。
服务器端获取连接信息的替代思路与注意事项
有些开发者实际想要的可能不是完整URI，而是找出哪些客户端正在连接数据库，或者把来源IP作为聚合维度。这类需求可以转向运维命令，而不是聚合管道。MongoDB的currentOp命令能够列出当前活动操作，并为每个操作返回client字段，一般是类似127.0.0.1:57622的客户端地址和端口。管理员可以运行以下命令查看连接来源。
db.adminCommand({ currentOp: 1, active: true }).inprog.forEach(function(op) {
print(op.client);
printjson(op.clientMetadata);
});
currentOp输出不会包含连接串里的密码，也不会提供完整URI，但它能帮助定位异常连接。如果需要把客户端IP纳入聚合计算，可以在应用代码里先获取本机或远程连接地址，再作为变量传入$group或$match阶段。例如Python驱动中可以检查client.address，Node.js驱动中可以读取client.options.hosts或从socket句柄反向解析，不过这些都属于客户端侧信息。
最后值得强调的是，$whatsmyuri这个名字即便出现在某些第三方教程、内部脚本或调试输出里，也并非MongoDB官方能力。它很可能是某个开发者为了调试临时封装的函数，或者是一个误解聚合管道能力的表述。遇到类似需求时，先确认数据属于文档集合、服务器状态还是客户端连接元数据，再选择正确通道。如果确实需要在聚合结果中标注客户端信息，就在请求入口处显式传入；如果是为了审计和观测，则应使用监控、日志和数据库命令。把边界理清之后，聚合管道的设计会干净很多。
