什么时候会动参数？
搞开发、调系统、跑服务，谁还没改过几个运行时的参数。比如线上接口响应慢了，顺手把超时时间从3秒改成10秒；或者日志太吵，临时关掉DEBUG级别输出。这些操作看着简单，但背后藏着不少坑。
先看权限，别越界
有些参数属于核心配置，普通账号根本没资格改。比如数据库连接池的最大连接数，运维可能只允许特定角色调整。贸然用脚本去写配置文件，轻则报错失败，重则触发安全审计告警，第二天就被叫去喝茶。
改之前记得留后路
最怕的就是改完立刻出问题，又记不清原来值是多少。建议动手前先把当前配置导出来存个档。比如用命令查Nginx的worker_connections：
cat /etc/nginx/nginx.conf | grep worker_connections记下来，或者拍张照都行。万一崩了，能快速还原。
热更新不等于无代价
很多系统支持参数热加载，比如Spring Boot的@RefreshScope，改完配置不用重启服务。但这不代表没副作用。比如你把线程池的核心线程数从5调到50，瞬间创建45个新线程，CPU可能直接拉满。老用户正在下单，结果卡住超时，锅就背上了。
别忽略上下游依赖
调一个参数，可能连累别的服务。比如把API的请求体大小限制从10MB提到100MB，听着爽快，但下游的处理程序可能撑不住这么大的数据，直接OOM崩溃。类似情况在微服务架构里特别常见，改一个，炸一片。
测试环境≠生产环境
本地测得好好的，一上生产就翻车。比如你在测试环境把重试次数设成10次，网络延迟低，每次重试200毫秒，总共也就两秒。但生产网络波动大，每次重试等两秒，10次就是20秒，用户早关页面了。这种差异必须提前摸清。
记录变更，别当黑盒操作
谁改的、什么时候改的、从啥值改成啥值，最好留下痕迹。哪怕是条简单的日志也好。不然半夜报警，排查一圈发现是三天前有人偷偷调了缓存过期时间，这种锅没人想背。
批量调整更要小心
要是在集群环境下批量改参数，别一股脑全推。可以先选10%节点试点，观察几分钟，没问题再 rollout 到全部。Kubernetes里的滚动更新就是这个逻辑。贪快一次性全改，容易集体翻车，恢复都来不及。
有些参数就是不能动
像加密算法、证书路径、主从切换开关这类敏感项，根本不该开放给动态调整。一旦被误操作或恶意修改，轻则服务中断，重则数据泄露。这类参数应该锁死，走审批流程才能动。