企业官网建设流程全解析

很多时候，我们干的活儿并不是什么高深莫测的架构设计，反而是那些每天都在重复的“查一下参数、改一个配置”。尤其是当你的手头同时管着 Windows 服务器和 Linux 服务器时，这种“精神分裂”的感觉会特别明显：明明在 Windows 上用图形界面点几下就能看到的东西，到 Linux 上就得敲命令；在 Linux 上顺手到不行的grep流水线，到 Windows 的 PowerShell 里又得换一套写法。这个系列就是为了解决这个问题而存在的——我会持续把 Linux 与 Windows 操作系统参数查询与配置的实用命令、排查思路和踩坑记录整理成文，既是自己的笔记沉淀，也给同样在这两个系统之间来回切换的朋友当一份速查手册。

今天这篇算是开篇，先把网络、内存、用户权限、服务管理、磁盘、日志这几个最常碰面的“参数查询与配置”场景各挑几个重点动作讲清楚。不追求面面俱到，但凡是写出来的，都是我实际用过、验证过、坑过之后才留下的干货。

1. 网络参数：IP、DNS 与端口的查询与配置实战

网络参数是系统管理里最基础也最高频的一项。服务器上不了网、端口不通、DNS 解析异常，这些问题不管在哪个系统上迟早都会遇到。关键在于：两边查这些东西的入口和语法完全是两套逻辑，如果只熟一边，临时切过去往往会卡壳。

1.1 Windows 侧的网络参数管理

Windows 上查看网络参数，老牌命令是ipconfig，在 PowerShell 里也可以用Get-NetIPConfiguration拿到更结构化的信息。我一般这样用：

ipconfig /all

这条命令能一次性看到所有网卡的 IPv4 地址、子网掩码、默认网关、DNS 服务器、DHCP 是否开启、MAC 地址等信息。排查“为什么这台 Windows 上不了网”时，第一件事就是跑它，先看 IP 是不是 169.254 开头的（这种情况基本就是 DHCP 没拿到地址，属于典型网络配置异常）。

如果是要修改 IP 地址，在图形界面下是“网络和共享中心 -> 更改适配器设置 -> 右键属性 -> IPv4 属性”，但用管理员权限的 PowerShell 更高效：

# 修改指定网卡的 IP 地址和网关 New-NetIPAddress -InterfaceAlias "以太网" -IPAddress 192.168.1.100 -PrefixLength 24 -DefaultGateway 192.168.1.1 # 修改 DNS 服务器 Set-DnsClientServerAddress -InterfaceAlias "以太网" -ServerAddresses 223.5.5.5,114.114.114.114

注意New-NetIPAddress在 repeated 使用时可能会报“此网络连接已有 IP 地址”，所以更多时候我会用Remove-NetIPAddress先清掉旧的再配新的，或者直接用带-Confirm:$false的脚本去批量处理。生产环境里这种变更尽量放在维护窗口做，毕竟一改 IP 远程连接立刻就断，手速再快也赶不上网络中断的速度，这一点不管在 Windows 还是 Linux 上都一样。

1.2 Linux 侧的网络参数管理

Linux 上现在的统一入口是ip命令，老牌的ifconfig基本已经退出历史舞台了。查看所有网卡和 IP：

ip addr show

看路由表和默认网关：

ip route show

ip系列命令输出的信息比ifconfig完整得多，而且不会像ifconfig那样在网卡没有 IP 时直接不显示该网卡，排查问题时少踩很多坑。

修改 IP 的方式在 Linux 下分成两种思路：临时生效和永久生效。临时修改用ip命令直接操作内核参数：

ip addr add 192.168.1.100/24 dev eth0 ip route add default via 192.168.1.1

但只要你重启网络服务或者重启机器，这些配置全都丢了。永久配置在大多数现代发行版里是通过 Netplan（Ubuntu 18.04+）或者 NetworkManager 来管。Ubuntu 下我习惯直接改/etc/netplan/下的 yaml 文件，例如：

network: version: 2 ethernets: eth0: addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 114.114.114.114

改完执行sudo netplan apply才会生效。这里有个常见的坑：远程连接服务器时如果你改错了 IP，netplan apply一执行连接立刻断掉。稳妥的做法是先用sudo netplan try，它会等你在超时时间内按回车确认，没确认就自动回滚，相当于一层保险。我在生产服务器上从来不敢直接apply，try才是正经操作。

有个细节顺便提一下：DNS 配置在 Linux 下也是个大坑。/etc/resolv.conf这个文件在很多发行版里是被 systemd-resolved 或 Netplan 托管自动生成的，你手动改完可能过一会儿就被覆盖。所以如果发现“改了 DNS 但cat /etc/resolv.conf又变回去了”，需要去检查是不是 systemd-resolved 在起作用，然后改成用resolvectl dns或修改 Netplan 配置来管理。

1.3 端口排查：两个系统下的高频实操

端口占用查不出来、服务起不来、端口被防火墙挡了，这类问题我在两个系统里遇到得最多，先把命令对照列出来。

Windows 下查指定端口被谁占用：

netstat -ano | findstr 8080

输出的最后一列是 PID（进程号），然后到任务管理器里按 PID 找对应进程；或者继续用命令：

tasklist | findstr 12345

如果你要杀掉这个进程，用：

taskkill /PID 12345 /F

Linux 下对应的操作：

ss -lntp | grep 8080

注意-p参数需要 root 权限才能看到进程名，否则只能看到端口监听状态。以前大家习惯用netstat，但新版系统里大概率没有，ss是替代它的现代工具，输出更快，信息也更全。找到 PID 之后杀进程：

kill -9 12345

两边走一遍下来你会发现，核心逻辑完全一致：查端口 -> 找 PID -> 杀进程。区别只在命令语法和参数的叫法不同。只要把这张对照表记在心里，切换系统排查时就不会慌了。

2. 内存与系统资源：怎么看、怎么读懂、怎么定位瓶颈

内存是另一个高频排查对象。服务器卡了，第一反应是看内存够不够；应用报 OOM 了，得查是谁把内存吃光的。Windows 和 Linux 在这块的排查路径差异很大：Windows 有完善的任务管理器，Linux 则只能靠命令行一点点抠。

2.1 Windows 的资源监控路径

Windows 上最直观的办法是打开“任务管理器 -> 性能”标签页，能直接看到物理内存的已占用、可用量、内存组成（缓存/已修改/备用）等。如果需要更细致的数据，用资源监视器（resmon）或者性能监视器（perfmon）可以追踪单个进程的内存随时间的变化趋势，定位“内存是不是在持续上涨”这类问题非常有效。

命令行场景下，PowerShell 也有对应的获取方式：

Get-Process | Sort-Object -Property WorkingSet64 -Descending | Select-Object -First 10 Name,Id,WorkingSet64

WorkingSet64是进程的工作集内存（物理内存中驻留的部分），大致能反映一个进程吃掉多少内存。注意不要只看这个数，因为 .NET 应用和 Java 应用往往有大量的虚拟内存占用，实际物理占用并不等于任务管理器里的“内存(专用工作集)”，这个认知偏差容易误导判断。

2.2 Linux 内存参数实战

Linux 下查看内存的第一命令是free -h：

free -h

看输出的时候，几乎每个新手都会被used那一栏吓到——怎么内存用了这么多？实际上 Linux 的内存使用逻辑里有一个“buff/cache”的概念，它会尽量把空闲内存用作文件缓存，来提高磁盘读写性能。所以判断内存是不是真的不足，主要看available这一栏，而不是used。

要定位具体哪个进程吃内存，用：

top -o %MEM

或者交互式地按大写M让进程按内存排序。top里有个细节：RES（Resident Memory，常驻物理内存）才是进程真正占用的物理内存，VIRT是虚拟内存，数值通常会大得离谱，光看VIRT没有实际参考价值。

我之前排查过一台内存告警的 Linux 服务器，free -h显示 used 高达 95%，结果仔细看发现大部分都是 Page Cache，应用实际可用的内存还很充足。后来通过sync; echo 3 > /proc/sys/vm/drop_caches手动清理了一下缓存，内存数值立刻降了下来。但要提醒的是，这条命令在生产环境要慎用，强制清缓存可能会导致磁盘读写性能短期波动，只在确认缓存占比过大的情况下才值得操作。

内存配置方面，Linux 有个容易被忽略的 swap 参数。查看 swap 使用情况：

swapon --show

如果 swap 的使用率长期很高，说明物理内存确实不够用了，这时候加 swap 只能算权宜之计，治本还是要加物理内存或者优化应用的内存占用。Windows 那边的虚拟内存（页面文件）也是同一个逻辑，不是说设得越大越好，关键还是物理内存要满足业务峰值需要。

2.3 进程资源占用排查对比

定位“谁把 CPU 打满”这个问题，两个系统的处理方式也值得并列放在一起看。

Windows 下直接用任务管理器按 CPU 排序就行，但有时候 CPU 占用率看起来只有 2%，系统却卡成幻灯片，那多半是磁盘 I/O 或内存瓶颈，不是 CPU 问题。命令行场景用：

Get-Process | Sort-Object -Property CPU -Descending | Select-Object -First 10

Linux 下对应top，按大写的P按 CPU 排序。另一个更直观的命令是htop，颜色区分 CPU/内存/负载，还支持直接按 F6 排序，体验比top友好不少。安装命令：

sudo apt install htop # Debian/Ubuntu sudo yum install htop # CentOS/RHEL

还有一个排查资源问题的通用思路：当进程的 CPU 占用很高时，用strace跟踪系统调用能看到它到底在干什么，Windows 对应的是 Process Monitor 里的“网络/文件/注册表”操作记录。这类工具虽然看起来复杂，但在真正疑难杂症面前，它们才是救命稻草。

3. 用户与权限：创建、授权与安全基线

权限管理属于那种“不出事岁月静好，一出事就是安全事故”的基础工作。用户权限配得太宽，内网横向移动就像逛自家后院；配得太死，同事马上来找你吐槽“怎么我又没权限了”。这节直接列出两边最常用的用户和权限操作。

3.1 Windows 用户与用户组

Windows 的本地用户管理在“计算机管理 -> 本地用户和组”里能找到，也可以直接用命令快速搞定：

# 创建本地用户 net user zhangsan P@ssw0rd /add # 将用户加入本地管理员组 net localgroup administrators zhangsan /add # 查看用户信息 net user zhangsan # 列出所有本地用户 Get-LocalUser

net user这个老命令从 Windows XP 时代一直用到今天，兼容性极好。但要注意：密码复杂度策略默认是开启的，如果你设置的密码太简单（比如纯数字、纯字母），系统会直接报错拒绝创建。排查这种问题的时候别一头雾水，先想想是不是密码策略挡住了。

Windows 权限里还有个概念叫 UAC（用户账户控制），即使你用的是管理员账户，如果 UAC 没有关，执行高权限操作时依然会弹确认框。命令行脚本里如果因为 UAC 导致权限不足，最简单的办法是用“以管理员身份运行”重新打开 PowerShell，而不是在普通窗口里折腾。

3.2 Linux 用户管理三板斧

Linux 用户管理的核心是三个命令：useradd（创建）、usermod（修改）、userdel（删除）。

# 创建用户并指定家目录和 shell useradd -m -d /home/zhangsan -s /bin/bash zhangsan # 设置或修改密码 passwd zhangsan # 将用户加入 sudo 组，获得管理权限（Debian/Ubuntu） usermod -aG sudo zhangsan # 对应 CentOS/RHEL 用 wheel 组 usermod -aG wheel zhangsan # 查看用户信息 id zhangsan

这里涉及的参数含义：-m是创建家目录，-d指定家目录路径，-s指定登录 shell。如果不加-m，用户可能连家目录都没有，登录后落到/下，后面遇到“为什么这个用户没有家目录”的报错，基本就是创建时少加了参数。

sudo 权限这边还有一个值得注意的安全习惯：不要轻易把用户直接加进sudoers文件里，更不要用visudo之外的方式去改这个文件。visudo自带语法检查，能防止你手误把 sudoers 改坏导致所有用户都无法提权。我自己就干过这种事，改完才发现语法错误，救援模式才救回来，从那之后只认visudo。

3.3 文件权限的坑

Linux 上查看文件权限用的是ls -l，显示的信息形如-rw-r--r--。这 10 个字符里，第 1 位是文件类型（-普通文件，d目录，l软链接），后面每 3 个字符一组，对应属主、属组、其他人的权限。

修改权限的基本操作：

# 给属主加执行权限 chmod u+x script.sh # 设置标准的生产权限：属主读写执行，属组读执行，其他人无权限 chmod 750 /data/app # 改变属主和属组 chown root:appuser /data/app

数值权限的算法其实很简单：r=4、w=2、x=1，三者相加就是最终的权限值。比如750就是属主 7（4+2+1，读写执行）、属组 5（4+1，读和执行）、其他人 0（无权限）。这个规则是我每次配权限都要在脑子里过一遍的默认值，生产环境的建议是：能不给其他用户权限就尽量不给，750往往比755更稳妥。

Windows 的文件权限体系则复杂得多，它是基于 ACL（访问控制列表）的，支持多个用户/组分别设定不同的“读取”“写入”“修改”“完全控制”等权限。命令行工具是icacls：

# 查看文件权限 icacls C:\data\app # 给指定用户授予完全控制权限 icacls C:\data\app /grant zhangsan:(OI)(CI)F

(OI)和(CI)分别表示“对象继承”和“容器继承”，意思是让这个权限继承到子文件和子目录。如果不加这两个标志，授权只会对当前目录本身生效，子目录完全不认账，很多“明明授权了还是没权限”的怪问题就是这么来的。

4. 系统服务与开机自启的运维控制

凡是需要长期运行的业务程序，要么注册成服务、要么用守护进程托管，否则系统一重启服务就没了，这种“重启后服务不见了”的教训在运维圈子里几乎人人都有过。两个系统对服务的控制机制差异也属于典型的一个南一个北，这里做一个完整对照。

4.1 Windows 服务管理

Windows 服务的管理可以通过“服务”管理单元（services.msc）图形化操作，但命令行和 PowerShell 更符合批量管理需求：

# 查看服务状态 Get-Service -Name wuauserv # 启动/停止/重启服务 Start-Service -Name wuauserv Stop-Service -Name wuauserv Restart-Service -Name wuauserv # 设置服务开机自动启动 Set-Service -Name wuauserv -StartupType Automatic

服务名不等于显示名。比如 Windows Update 服务的显示名是“Windows Update”，但服务名是wuauserv。写脚本时搞混了服务名，命令直接报错找不到服务。要查所有服务和显示名的对应关系，运行：

Get-Service | Select-Object Name,DisplayName,Status

还有一个高频场景：程序装好后怎么让它开机自启？最简单的做法是把快捷方式放到shell:startup目录，但这种方式不适用于服务类程序。如果要让一个程序以服务方式运行，官方做法是用sc.exe create注册服务：

sc.exe create MyService binPath= "C:\path\to\app.exe" start= auto

注意sc.exe的等号后面必须带一个空格，binPath= "..."中间的空格不能省，否则参数解析会失败。这个细节我头几次用的时候踩过好几次坑，报错信息也不够直观，现在写出来提醒一下。

4.2 Linux 服务管理

systemd 是当代 Linux 发行版的主流服务管理器，几乎所有常见的发行版都在用它。最常用的操作：

# 查看服务状态 systemctl status nginx # 启动/停止/重启 systemctl start nginx systemctl stop nginx systemctl restart nginx # 设为开机自启 systemctl enable nginx # 同时完成 enable 和 start systemctl enable --now nginx

systemctl enable --now是我在部署新服务时最喜欢用的组合参数，一步到位，不用先 enable 再 start 分两次执行。反过来，disable --now可以一次完成取消自启和停止服务，清理下线服务时很方便。

systemd 服务单元文件的存放位置是/etc/systemd/system/，一个典型的服务文件长这样：

[Unit] Description=My Custom Service After=network.target [Service] ExecStart=/usr/local/bin/myapp Restart=always User=myappuser [Install] WantedBy=multi-user.target

这里需要解释几个关键参数：After=network.target表示服务要在网络就绪后再启动，避免程序一启动就发现网络不可用；Restart=always是服务崩溃后自动重启的策略，生产环境里基本必加；User=指定以哪个用户身份运行，千万不要用 root 跑业务服务，安全风险很大。修改完服务文件后要执行systemctl daemon-reload重新加载，然后才能systemctl restart让新配置生效。

我发现一个高频的坑是：服务配置里的程序路径写错了，systemctl start会报错，但报错信息有时候并不直观。排查这类问题直接跑systemctl status 服务名，它会在下边显示进程日志的最后几行，基本能定位到问题所在；不够的话再用journalctl -u 服务名看完整日志。这个查询习惯我建议每个人都养成，比盲改配置高效得多。

5. 磁盘与存储参数：挂载、扩容与排查

磁盘满了导致服务写不了文件，这是运维里最常见的“低级却又致命”的问题。两个系统的磁盘排查和扩容操作各自有一套流程，命令行风格也差别很大，这节把它们对应着讲清楚。

5.1 磁盘查询命令对照

Windows 下查询磁盘空间：

Get-PSDrive -PSProvider FileSystem

这个命令会列出所有盘符的已用空间和剩余空间，比打开“此电脑”看属性要快得多。如果是要对磁盘做更底层的操作（分区、格式化），Windows 的命令行工具是diskpart：

diskpart list disk select disk 0 list partition

diskpart是交互式工具，得一行一行地进。不熟悉它的情况下，建议先用list disk看清楚磁盘编号再动手，不然选错磁盘格式化到系统盘，后果不堪设想。

Linux 下查看磁盘空间：

df -h

-h参数让大小以易读的 G/M 格式显示。如果df -h显示某个分区已经 100%，但你不确定是什么占的，就用du逐步查：

du -sh /* du -sh /data/*

这个“从根目录一层层往下找占用大户”的思路，是排查磁盘满的标准流程。du -sh的-s是指只显示总和，-h同样是人类可读格式。

5.2 Linux 扩容后分区调整

大多数云服务器在控制台里扩完磁盘容量后，Linux 系统并不会自动识别新增的空间，需要手动执行分区调整和文件系统扩容。这里以最常见的 LVM 场景为例：

# 查看当前卷组和逻辑卷 vgdisplay lvdisplay # 扩展逻辑卷（假设新增空间已合并到卷组） lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv # 扩展文件系统 resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

先扩逻辑卷，再扩文件系统，顺序不能反。如果先扩了文件系统而底层逻辑卷没有空间，命令会直接报错。还有一点：XFS 文件系统的扩容命令是xfs_growfs，不是resize2fs，用错了会提示“Filesystem at ... is not an ext filesystem”。CentOS/RHEL 默认文件系统通常是 XFS，Ubuntu 默认是 ext4，在扩容前先df -T确认文件系统类型，能避免很多无谓的报错。

Windows 侧的磁盘扩容相对简单：在“磁盘管理”里右键要扩展的卷选“扩展卷”，按向导走就行。但有个前提条件，目标分区后面必须有未分配的连续空间，否则“扩展卷”是灰色的不可点击。这种时候往往需要先把后面的分区删掉或者用第三方工具移动分区，操作风险很大，务必提前备份数据。

6. 日志与安全审计：出了问题往哪查

日志系统决定了排障效率的上限。出问题时如果日志路径和查询方式都很清楚，基本几分钟就能定位；如果连日志在哪儿都找不到，那就只能瞎猜了。Windows 和 Linux 的日志体系差别极大，这里是两套完全不同的哲学。

6.1 Windows 事件日志

Windows 的日志统一由“事件查看器”管理，命令行对应的 PowerShell 命令是Get-WinEvent：

# 查看最近 20 条系统日志 Get-WinEvent -LogName System -MaxEvents 20 # 按事件 ID 筛选（比如内核恐慌 41、意外关机 6008） Get-WinEvent -LogName System -MaxEvents 200 | Where-Object { $_.Id -eq 6008 } # 查看安全日志中最近的登录成功/失败记录 Get-WinEvent -LogName Security -MaxEvents 50 | Where-Object { $_.Id -in (4624,4625) }

事件 ID 的玩法在 Windows 排障里非常实用。比如 4624 是成功登录，4625 是登录失败，6008 是异常关机。遇到服务器半夜自动重启这种问题，直接在安全日志里筛 6008 和 4624，比在图形界面里肉眼翻效率高得多。

Windows 还有一个东西叫“应用程序日志”，记录的是应用层报错。如果你的 Java 或 .NET 程序在 Windows 上崩溃了，除了去看程序自己的日志文件，也可以去“应用程序”日志里碰碰运气，报错堆栈有时候会直接写到那里。

6.2 Linux 日志体系

Linux 的日志体系以 syslog 为核心，systemd 时代统一走journald。最常用的查询命令是journalctl：

# 查看所有日志，按时间倒序 journalctl -xe # 查看指定服务的日志 journalctl -u nginx # 从上次启动后的日志（排查重启后问题） journalctl -b # 实时跟踪日志输出 journalctl -f

-xe里的-e是跳到日志末尾，-x是补充信息提示，组合起来就是“直接看最近发生的事情”，这是我登上任何一台出问题的服务器第一时间敲的命令。

传统日志文件在/var/log/目录下：/var/log/messages（或/var/log/syslog）记录系统整体运行信息，/var/log/secure（或/var/log/auth.log）记录认证和安全相关日志，/var/log/dmesg记录内核环形缓冲区的消息。排查登录被爆破、SSH 异常登录时，直接翻认证日志是最快的入口：

grep "Failed password" /var/log/auth.log | tail -50

说到安全审计，Windows 那边的auditpol和 Linux 这边的auditd都是类 Unix/Linux 的审计框架，功能定位也类似，但配置复杂度都很高。日常工作中如果不是有合规要求，我一般依靠系统自带的安全日志就够用了，重点是养成定期翻日志的习惯，而不是等到出大事才想起来查。

7. 这个系列怎么持续维护：我的更新方法与经验

既然标题写了“持续更新中”，我就顺便聊聊这个项目背后我是怎么维护它的。这既是给读者一个交代，也是把我的笔记方法分享出来——毕竟“会记笔记”和“会用笔记”本身也是一项技能。

7.1 每篇内容的结构化处理

我不建议把命令随手扔进一个没分类的 txt 文件里。我现在整理这类速查内容的做法是，按照“场景 -> 命令 -> 参数解释 -> 预期输出 -> 踩坑点”的五段式结构展开：

• 场景：什么情况下会用到这条命令；
• 命令：完整可复制的命令原文；
• 参数解释：每个关键参数的含义和为什么加这个参数；
• 预期输出：正常情况会看到什么；
• 踩坑点：这条命令常见的坑是什么。

这个结构的好处是，几个月后翻回来，不需要重新回忆“当时为什么要这么写”，输出和原理都在旁边写明白了。很多网上的速查表只给命令不给解释，表面上看着全，实际用起来还是得一个个去搜，效率反而更低。

7.2 持续更新的节奏

维护这种系列内容最难的不是写，而是“持续”。我的经验是不要等自己整理出一大堆再来发布，而是遇到一个真实问题、解决完顺手记录，积累到三五条就更新一篇。比如今天排查了 Elasticsearch 在 Windows 启动报错，明天解决了 Redis 在 Linux 上的内存参数配置，这些都是天然的写作素材。

另外，我建立一个简单的分类文件夹来存命令笔记的 markdown 文件，命名规则是“日期_场景关键词”，比如20250115_linux瓦查内存.md。这个习惯坚持大半年后，你会发现自己的知识库越来越厚，而且每一条记录都带着当时的实际场景，比从网上复制粘贴来的命令有价值得多。

7.3 一些个人的体会和后续计划

实际做这个系列之后，我有一个很深的体会：Linux 和 Windows 之间的很多差异，表面上是命令不同，骨子里是设计哲学不同。Linux 强调“一切都通过文件暴露，一切都能用脚本控制”，所以命令行永远是它的主场；Windows 则一直试图用图形界面包裹底层逻辑，命令行更像是一个“给高级用户留的后门”。理解了这层差异，学起来就不会觉得两个系统之间的转换有多么痛苦，而是把它们当成解决同一类问题的两把不同形态的钥匙。

这个系列的后续更新，我打算按照操作系统参数的热门方向分篇推进：安全基线配置、内核参数调优、远程管理加固、监控指标采集，这些方向都会挨个展开。每一篇都会保持今天的风格——命令、参数、实际输出、踩坑记录，缺一不可。如果各位读者在平时操作里遇到了什么让我也会心动的“怪问题”，欢迎在评论区丢过来，我踩过坑之后很可能就是下一篇更新内容。