真正能安全调整的参数需满足：不破坏内核契约、适配业务场景、容器中可生效；乱调如vm.overcommit_memory=0、net.ipv4.tcp_fin_timeout过低、vm.swappiness=0等易致崩溃或OOM；容器内fs.file-max等受cgroup限制，kernel.hostname等不生效；调参前须用ss -s、/proc/meminfo、vmstat验证瓶颈。
哪些参数真能调，哪些调了反而坏事
不是所有 /proc/sys 下的参数都适合生产环境动。有些参数看似“性能相关”，实则是内核行为的底层契约，乱改会直接破坏 TCP 状态机、OOM 判定逻辑或内存隔离机制。比如 vm.overcommit_memory=2 配合 vm.overcommit_ratio 是安全的严格分配策略，但若设成 vm.overcommit_memory=0（启发式分配），在 Redis 或 Java 应用密集 fork 子进程时，可能让内核误判“还有内存”，结果 malloc() 成功后首次写入就触发 SIGBUS —— 这种错误根本不会报 OOM，而是静默崩溃。
容易踩坑的典型参数包括：
-
net.ipv4.tcp_fin_timeout：从 60 改到 15 看似加速回收，但如果后端服务依赖 FIN_WAIT_2 等待对端 ACK（如某些老旧负载均衡器），连接可能被中间设备提前中断； -
vm.swappiness=0：数据库场景常被推荐，但一旦发生内存突发申请（如 MySQLALTER TABLE加索引），没有 swap 缓冲空间，OOM Killer 会立刻干掉 mysqld 进程，比换出部分页更危险； -
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog设得过高（如都设成 65535），但应用层没同步调大 listen backlog（如 Nginx 的listen 80 backlog=4096），内核队列扩了也没用，还可能掩盖应用层瓶颈。
容器环境里，哪些参数根本调不动
宿主机上改了 net.ipv4.ip_local_port_range，容器里 curl 发起的连接确实能用上新端口范围；但改 fs.file-max 只影响宿主机全局上限，容器内看到的 /proc/sys/fs/file-nr 仍是它自己的 cgroup 限制 —— 这个值由 docker run --ulimit nofile=65535:65535 或 K8s 的 securityContext.limits 控制，和宿主机 fs.file-max 没有继承关系。
真正“跨不进容器”的参数有：
-
kernel.hostname、kernel.domainname：容器默认是独立 UTS namespace，宿主机修改无效； -
vm.dirty_ratio、vm.dirty_background_ratio：这些是全局内存策略，容器共享宿主机 page cache，所以生效，但副作用是会影响所有容器的刷盘节奏； -
net.ipv4.conf.all.forwarding：虽然容器 netns 默认关闭转发，但如果你在宿主机启用了net.ipv4.ip_forward=1，且容器用hostNetwork或配置了 iptables 规则，它就真能转发 —— 所以这个参数不是“不能调”，而是“调了会穿透 namespace 边界”，必须意识到影响范围。
压测没看到提升？大概率你调错了地方
很多团队在 QPS 上不去时直接翻“Linux 高并发优化清单”，把 net.ipv4.tcp_tw_reuse=1、net.core.somaxconn=65535 全加上，结果压测延迟纹丝不动。原因往往是：瓶颈根本不在内核网络栈。比如用 perf top 发现 40% CPU 耗在 pthread_mutex_lock，说明是应用层锁竞争；或者 ss -s 显示 TCP: inuse 1200，远低于 ulimit -n 的 65535，那 net.ipv4.ip_local_port_range 再宽也没意义。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
验证是否真该调内核参数，优先跑这三行：
-
ss -s：看实际连接数、TIME_WAIT 数量、内存队列是否打满； -
cat /proc/meminfo | grep -E "MemAvailable|SwapFree"：确认是不是内存吃紧导致频繁回收页缓存； -
vmstat 1 5：观察si/so（swap in/out）是否非零，bi/bo是否持续高位，判断 I/O 是否卡住内存路径。
如果这三项都正常，还硬调 vm.vfs_cache_pressure 或 net.core.rmem_max，就是在给健康系统做阑尾切除术。
为什么 sysctl --system 有时不生效
你以为执行了 sysctl --system 就万事大吉，但实际参数可能被覆盖或忽略。常见原因有：
- 文件加载顺序：系统按字母序读
/etc/sysctl.d/*.conf，如果你的自定义文件叫10-custom.conf，而系统自带的50-default.conf里又写了同名参数（比如某些云厂商镜像会预置），后者会覆盖前者 —— 解决办法是命名成99-custom.conf； - 模块未加载：比如想开
net.ipv4.tcp_fastopen，但内核没编译CONFIG_TCP_FASTOPEN或模块未加载，sysctl -w会报 “Invalid argument”； - 只读参数：部分参数（如
kernel.osrelease）是只读的，sysctl -w会直接失败，但错误信息很隐晦，需结合dmesg | tail看内核日志。
最稳妥的做法：每次修改后，用 sysctl -n 参数名 确认输出值已变，再结合业务请求验证效果 —— 内核参数不是写完就生效，而是写完+被业务路径真实触达才起作用。
