1. 先搞清楚：参数传递到底在传什么
1.1 从一次函数调用看单向传递
“把变量扔进函数，函数内部改了，结果外部也跟着变了？” 这是好多新手栽过的跟头。要理解单向传递和双向传递，最好先看一次最简单的函数调用背后发生了什么。比如下面这段 C 代码：
void increase(int x) { x = x + 1; } int main() { int a = 10; increase(a); printf("%d\n", a); // 输出 10 }这里increase(a)把a的值复制了一份给形参x。x是函数栈上新开辟的变量，和a各自占一块内存。函数里改x，根本碰不到a。这就是标准的单向传递：数据从调用方流进被调函数，但函数没有能力把结果“传回去”。你可以把它想成你把一张照片的复印件交给别人，别人在复印件上随意涂画，原件始终是干净的。
这种设计非常安全。别人拿不到原件，自然不用担心内部逻辑把你的数据搞得一团糟。也因为数据流方向只有一个，排查问题时只需要追踪“进入函数”这条线，模块边界非常清晰。所以绝大多数编程语言在默认情况下都选择按值传递，也就是单向。
1.2 双向传递到底是怎么发生的
那双向传递又是怎么实现的？最直观的做法是通过指针或引用。同样一段逻辑，用 C++ 的引用改一下：
void increase(int &x) { x = x + 1; } int main() { int a = 10; increase(a); cout << a << endl; // 输出 11 }这里的&x是变量a的别名。函数内部操作的x就是外部的a，同一个内存单元。数据先传进去，函数改完，外部变量立刻变成了新值。这就是双向传递：信息从调用方流向函数，函数又通过同一块内存把结果反馈给调用方，一个参数上承载了“流入”和“流出”两个方向。
需要特别提醒的是：返回值并不算双向传递。返回值是函数把结果单向送回给调用方，整个过程由“参数进入”和“结果返回”两段独立的单向通道组成，并不是在同一个参数上来回流动。很多面试题喜欢在这个点上挖坑：如果函数要返回多个结果怎么办？有人会想到用多个引用参数，有人会返回结构体，还有人会用全局变量。用引用来修改外部变量，本质上是共享了可变状态，这带来了方便，也带来了副作用管理成本。
1.3 方向性背后的所有权思维
单双向之争，说到底是个所有权问题。单向传递意味着调用方保留数据的完整所有权，被调函数拿到的只是临时副本或只读视图；双向传递则是把访问权临时借给对方，让对方在原始数据上动手。现代语言越来越倾向于减少隐式双向传递。比如 Rust 通过所有权和借用机制，在编译期就把“我只读一下”和“我要改你”分得明明白白；Go 里 slice 虽然按值传递，但底层引用同一个数组，函数里 append 到一定程度会表现出双向修改的效果，这又让不少新人摸不着头脑。
理解所有权之后，很多设计决策就顺了：这个参数该不该允许被改？如果只想读，尽量传 const 或不可变对象；如果确实需要被修改，就明确使用引用或指针，并且在函数名、注释里写清楚“此参数会被原地修改”。不要让对方猜，猜就会出错。
2. 不同语言里单向和双向的“变形计”
2.1 C/C++：指针、引用和 const 的三角关系
C 语言里只有指针。形参写int *p，传进来的是变量地址，函数内*p = ...就能修改调用方的变量；如果不想被修改，就加const int *p。这是最原始的单向/双向控制手段。但指针容易出错，常见问题包括忘了解引用、把指针本身改了、传了空指针却没有判空。
C++ 增加了引用int &x，语法更自然，写函数时不需要拿地址、传地址、解引用，也不存在空引用，比指针安全很多。但引用一旦绑定对象就不能换绑，也不能直接存放在容器里，所以很多场景还是得退回指针。我实际开发中，优先用引用做输出参数，因为读代码的人一眼能看出函数要修改实参；如果表示可选参数或者多态对象，我才会选指针。再配合const，就能表达出“只读的引用”“只读的指针”“可修改的引用”等不同方向，语义层级非常丰富。
2.2 Java 和 Python：被误会的“引用传递”
Java 的基本类型（int、double）严格按值传递；对象呢，传的是“对象的引用”本身的值。听起来很绕，但实际效果是：你把一个对象传进方法，方法里修改对象的属性，外部能看到；如果你在方法里给这个引用重新赋值一个新对象，外部变量指向的还是旧对象。Python 也一样。很多人把它说成“引用传递”，其实是“对象引用按值传递”。
这个特性带来一个典型坑：被调函数能就地修改可变对象（list、dict、对象字段），但没法改变调用方的变量绑定。想让函数“整个换掉一个对象”，只能返回新对象再赋值，或者传入一个持有该对象的容器，比如List、包装类。我在设计 API 时，习惯在文档里明确写：“本方法会修改传入的 list”或“调用后请丢弃原引用”。否则调用方以为没变，实际已经被改了，线上排查时非常难受。
2.3 回调、信号槽和事件里的参数方向
参数的方向问题不只在普通函数里，回调函数、消息队列、信号槽也很常见。以 Qt 信号槽为例：信号发出时把数据单向传给槽函数，槽函数处理完若想反馈给发送者，一般通过发另一个信号，或者捕获引用、成员变量间接实现。多线程场景下，队列连接会把参数拷贝一份再投递给槽函数，而直连是在同一个线程栈上直接调用，参数如果是指针，很容易产生两个线程读写同一块内存的竞争。
我印象很深的一次事故：子线程通过信号把一个大对象发射给主线程，用的直连方式，两个线程同时共用一个 QByteArray，结果偶发崩溃。后来改成队列连接，并确保参数是可以拷贝的隐式共享类型，才彻底稳定。这说明事件传递里的单向/双向，不只是语义问题，还涉及线程安全和对象生命周期。
3. 实操场景：从脚本传参到 Web 路由，到处都是方向控制
3.1 命令行脚本：Start-Process 的 ArgumentList 为空报错
写脚本时给另一个程序传参，最常见的是 sys.argv、argparse 这类机制。PowerShell 里用 Start-Process 启动外部程序时，有个很常见的报错：
Start-Process -FilePath "python" -ArgumentList $args -Wait如果$args为空或 null，就会提示“无法对参数‘ArgumentList’执行参数验证。参数为 null 或空”。这本质上也是一个参数方向问题：调用方没把参数传过去，被调进程收到的就是空。我的处理方式是先构造一个空数组，再判空：
$argList = @() if ($args) { $argList = $args } Start-Process -FilePath "python" -ArgumentList $argList -Wait命令行传参永远是单向的：程序内部怎么改参数，都影响不到外部调用方。想要把结果拿回来，只能靠文件、环境变量、共享内存、Socket 等方式回传。这是操作系统进程边界的限制，理解了这一点，就不会再去纠结“为什么我不能传引用给另一个进程”。
3.2 Web 前后端传参：Ajax 和 Vue 路由
前端给后端传参，GET 用 query，POST 用 body。后端处理完返回 JSON，这是标准的单向请求-响应模式。Ajax 里常见这样的写法：
$.ajax({ url: "/api/user", type: "POST", data: { id: 1, name: "zhang" }, success: function(res) { // res 是后端返回的数据，方向从后端到前端 } });这里的data是“发送给后端”的单向参数，success回调里的res是“后端返回的”单向数据。它们并没有在同一个“参数”上双向流动。如果页面里某个值要在提交后更新，本质上是反复执行了多次单向过程，而不是参数自己会变。
Vue Router 的params和query也常被搞混。使用 params 时，必须保证路由定义里有对应的占位符，比如/user/:id。如果路径写成了/user，然后直接router.push({ params: { id: 1 } })，参数会因为路由不匹配而丢失，跳转后页面拿不到值。路由参数的方向很明确：从当前页传到目标路由，目标页改不了发送方的数据。想要跨页同步状态，只能靠全局 store 或事件总线，那已经不属于路由参数传递的范畴了。
3.3 并发和压测工具中的参数隔离
用 JMeter 做并发压测时，如果 10 个线程共用一个变量，或者所有请求体里的参数是同一个固定字符串，结果就会互相干扰。想实现“并发十个参数不同的 POST 请求”，通常要配合 CSV Data Set Config，让每个线程从数据文件里取不同的行；或者用__V()函数动态拼参数。我之前做过一个接口压测，因为参数固定，服务器反复更新同一条记录，看起来并发量很高，实际根本没测出真正的瓶颈。
这里的参数方向是：测试线程把各自参数单向发给被测系统，系统返回响应，测试脚本收集响应。如果参数之间不隔离，就像把多条“单向传递”强行混成了一条共享通道，数据全缠在一起。正确做法是保证每个线程使用独立参数副本，并在断言里确认响应和请求一一对应。
4. 常见问题与排查技巧实录
4.1 可变对象默认参数：函数“记住”了上一次调用
Python 里最经典的参数坑，就是可变默认参数：
def add_item(item, items=[]): items.append(item) return items第一次调用add_item('a')返回['a']，第二次调用add_item('b')返回['a', 'b']。原因是默认列表在函数定义时只创建一次，后面所有调用都共享同一个对象。这算单向还是双向？表面看是“传入列表然后原地修改”，但因为默认列表本身是共享的可变对象，即使你不传参数，函数也修改了外部可见状态。
解决办法是把默认值设为 None：
def add_item(item, items=None): if items is None: items = [] items.append(item) return items排查这个问题时，第一眼看函数默认值是否是可变类型，第二眼看函数体内有没有对参数做append、update、add这类原地操作。
4.2 参数意外被修改：别把“读入”当成“写入”
我遇到过导出 Excel 的功能，函数内部写了list.sort()，结果外部传入的列表被原地排序，调用方原本的顺序全乱了。后来改成sorted(data)生成新列表才解决。这是团队里最常见的双向传递 bug：开发者以为参数只是“传入数据”，没想到函数内部偷偷做了修改。
建议养成两个习惯：第一，API 设计时，参数如果只读，就声明const或final；如果语言不支持，就在命名上区分，比如inputList和listToModify。第二，Code Review 时重点关注函数是否对参数做原地修改。这不是性能问题，而是语义清晰问题，能避免大量隐蔽的副作用。
4.3 多线程传参：moveToThread 之后的参数生命周期
Qt 里用 QThread 跑任务，常见写法是：
QThread *thread = new QThread; Worker *worker = new Worker; worker->moveToThread(thread); connect(thread, &QThread::started, worker, &Worker::doWork); thread->start();如果doWork需要参数，一般通过信号连接传过去。按钮点击信号没有参数，就需要自定义一个带参数的信号，或者用 lambda 捕获参数。lambda 捕获this指针或局部变量时要格外小心：线程还没处理完，对象就被销毁了，程序直接崩。这是典型的生命周期问题，比方向问题更隐蔽。
排查多线程传参时，先确认连接类型：队列连接会把参数拷贝到消息队列，比较安全，但性能略低；直连则直接调用，参数如果是可变对象，可能产生数据竞争。我通常的做法是：Worker 内部自己定义信号和槽，参数用值传递或隐式共享类型，绝不把裸指针从一个线程传到另一个线程。
4.4 快速排查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 函数改了参数，外部变量没变 | 基本类型按值传递 | 检查是否用了引用/指针，是否传了可变容器 |
| 外部变量被函数意外修改 | 函数对可变对象做了原地操作 | 搜索函数体中的 sort/append/update，改成拷贝 |
| 并发请求参数串号 | 所有线程共享了同一个参数对象 | 为每个线程创建独立请求体，或用数据源组件 |
| 点击按钮后槽函数参数不对 | 信号与槽的参数类型不匹配 | 检查 connect 签名，或自定义带参信号 |
| 启动进程报 ArgumentList 为 null | 参数列表为空或未处理 | 先判空，再用 @() 传给 Start-Process |
这个表是我平时排查类似问题时的第一入口。遇到情况先对号入座，能省不少时间。
5. 设计参数时，我优先考虑的四件事
5.1 能用单向就别用双向
单向传递意味着更少的副作用。函数最好是一个纯函数：输入确定，输出确定，不碰外部状态。纯函数最好测试，也最好维护。如果一段逻辑只是要根据输入算出一个新结果，那就应该返回新值，而不是原地改参数。这个原则适用于绝大多数业务代码。
5.2 真的要改参数？把输出参数写得明明白白
我早期写过这样一个 C 函数：
int validate_and_parse(const char *s, int *out_len, int *out_value);返回值是状态码，两个指针是输出参数。调用方如果不看文档，很容易误以为out_len是输入配置项。后来我改成了返回结构体：
typedef struct { int value; int len; } ParseResult; ParseResult parse(const char *s);返回结构体比输出参数直观得多。如果出于性能必须用输出参数，我会在参数名前加out_前缀，并在注释里醒目地写上“此参数会被函数修改”。这个习惯帮我避免了大量误用。
5.3 超参数、硬件参数不是“双向传递”，而是“调优回路”
像 TP4056 充电芯片、LM317 三端稳压器、GMII 接口时序、LCL 滤波器设计这类硬件参数，本质上是“单向配置”：你把参数值设给模块，模块按参数工作，参数本身不会回来。真正的调优过程是“设置-测量-修正”的外部循环，你和被测系统之间来回往复，但这不是参数本身的双向传递。
同理，YOLOv5 的超参数、SVM 的核函数参数、KCF 跟踪算法的参数，都属于模型“单向摄入”的配置。调参时，算法不会把一个参数改好后递给你，而是你反复执行“设置参数-运行评估-调整参数”。这种“外部优化回路”很容易被误解成双向传递。分清之后，你在做调参平台时就不会执着于“让模型把参数传出来”，而是把注意力放在评估指标的反馈上。
5.4 参数生命周期比方向更容易出问题
方向决定了“能不能改”，生命周期决定了“改完还在不在”。C++ 里把引用传给一个已经析构的对象，函数执行时可能没报错，但函数返回后引用就悬空了；Qt 信号带指针跨线程，队列拷贝的参数如果指向的对象被提前释放，槽函数里一访问就崩。我在工程实践里的经验是：先确认对象死没死，再确认能不能改。
进程间传参更是如此。Hadoop distcp 有好多参数：-m控制 map 数，-bandwidth限制带宽，-update做增量同步。这些参数是单向传给 MapReduce 作业的，作业跑完不会修改这些参数。你要拿结果，只能看日志、退出码或输出目录。这种系统边界上的单向性，一旦被忽略，就容易出现“启动了一个后台任务，然后傻等它改回某个变量”的笑话。
6. 真遇到双向传递需求，这三个替代方案更稳
6.1 返回复合对象
如果函数需要输出多个值，优先考虑返回结构体、元组或数据类。Python 用namedtuple，Java 用record，C++ 用std::pair或自定义 struct。比如一个统计函数要返回均值、最大值、最小值，直接返回一个三字段对象可比传三个引用参数清晰多了。调用方拿到后自己解包，也不会被函数偷偷改掉已有变量。
6.2 用回调或事件代替共享引用
需要异步反馈时，用回调或事件比共享变量安全。请求参数只有“进入”的方向，执行完通过回调参数把结果带回来。两个方向都被函数签名显式表达出来，调用双方各取所需，谁也不会在不该改的时候去动别人的变量。前端的 Ajax success 回调、Qt 信号槽、Node.js 的 callback，都是这个套路。
6.3 用共享状态容器管理复杂协作
当你确实需要多处协同修改同一个状态时，比如 Vuex、Redux，或者进程内的全局配置，不要靠层层传参去传引用，而是定义一个独立的状态仓库，所有模块通过接口读写。状态仓库把“双向传递”升级成了“多向订阅”，比在调用链里来回传参更容易维护。
这种思路在分布式系统里更明显。比如 Tomcat 启动时设置的 JVM 参数，是单向传入 JVM 的配置；但你想在运行时读取或修改某些参数，必须通过 JMX 接口操作，而不是把启动参数的引用传进每个线程。VSCode 查看 Python 函数参数也是如此，它只是静态读取函数签名展示给你，并没有改变任何参数。分清这些场景，你就知道什么时候只是“展示参数”，什么时候真的需要“双向协商”。
6.4 我坚持的几个原则
这些年写代码，我逐渐总结出几个非常朴素的原则：凡是入参，默认只读；需要读写，参数名或类型上要写清楚；跨线程或跨进程，一律走消息或事件机制，不做裸共享内存；如果返回值能表达结果，就别用输出参数。这些原则不一定最优雅，但能省下大量排查时间。
参数的单向与双向，说到底不是语法考点，而是模块之间约定的边界。边界清晰了，bug 自然就少了。愿你下次再看到“参数”两个字时，第一反应是“这个数据从哪来，到哪去，中途能不能被改”，而不是“怎么写个引用传参”。能有这种意识，比背一万条语法规则都管用。
