搞Linux的人早晚都会在账号和权限上栽一次跟头。我见过刚转行的运维第一天上岗就把root密码改得连自己都猜不回来也见过老手图省事一个命令带着777权限跑完整个清理任务结果把项目的共享目录权限全部打乱全组陪着他排查到凌晨。账号和权限管理听起来是最基础、最不起眼的日常操作但恰恰是每台Linux服务器的地基。地基一旦松动上面的服务、数据、备份、定时任务全都悬在半空。这篇分享想把这摊事从头到尾捋清楚从UID、GID这些底层概念到useradd、passwd、chmod这些高频命令再到ACL、sudo、PAM这些进阶玩法最后给一套完整的多人协作环境搭建案例附上我平时踩坑总结的排查思路。适合两类人一是刚接触Linux的入门者能借此把零散命令串成体系二是已经用了Linux一段时间、但一直没有认真想过权限模型的老同学——看完以后你至少能回答三个问题每个命令到底在改什么、权限报错该往哪个方向查、怎么设计一套够用又不留后门的账号方案。1. 先搞清楚这盘棋的规则1.1 账号不只是名字UID、GID与身份识别很多人以为账号就是用户名加密码其实在Linux眼里用户名只是给人看的一张铭牌内核真正认的是两个数字UID用户ID和GID组ID。当你执行ls -l看到的文件属主是alice其实磁盘上记录的是alice的UID内核在判定这个文件能不能被你改的时候看的就是你进程的有效UID和文件属主UID对不对得上。所有用户名字符串到UID数字的映射统一存在/etc/passwd里。所以如果两个不同名称的用户被误写成同一个UID在系统看来他们就是同一个人权限部分完全共享。这个坑后面会详细讲。GID同理文件记录的是属组GID组名映射在/etc/group里。每个用户必有一个主组还能额外加入若干个附加组。判断权限时附加组同样有效这就是为什么wheel、docker这类组加进去就能获得对应权限。查看当前身份最直接的命令是idid uid1000(alice) gid1000(alice) groups1000(alice),10(wheel)这个输出值得逐字段看一遍uid1000是你的真实用户身份gid1000是主组groups后面列出的是包括主组在内的全部有效组。看清楚这一点很多权限问题已经解决一半了——比如你明明把自己加进docker组却还是报无权限大概率是组信息没刷新得重新登录或者用newgrp docker切换到新组。顺便说一句第一次在服务器上执行id发现预期中的组没出现别急着怀疑配置有问题多半只是当前会话还带着旧的身份缓存。注意Linux下创建文件后文件的属主取自当前进程的有效UID而不是登录时用的用户名。用sudo执行命令时文件属主会变成root这一点在写脚本时尤其容易踩。1.2 账号的分类与配置文件结构系统里的账号大致分三类rootUID 0、系统账号各发行版略有差异通常UID 1到999、普通用户一般从1000开始。root的权力必须反复强调它不受文件权限位约束能读能写任一文件前提是应用层别被SELinux这类机制拦住。系统账号专门用来运行服务数据库、消息队列等它们通常没有家目录或者家目录放在/var/lib下而且默认Shell是/sbin/nologin意思是这个账号只能跑服务不能拿来登录。理解账号体系绕不开两个核心文件。/etc/passwd每一行一个账号冒号分隔的七个字段字段示例含义用户名alice登录用的名字密码占位符x真正的密码在shadow里UID1000用户IDGID1000主组ID备注Project MemberGECOS信息家目录/home/alice登录后所在目录Shell/bin/bash默认解释器看到密码位是x千万别以为密码就藏在passwd文件里。现代Linux密码哈希都存在/etc/shadow只有root能读shadow里每一行有9个字段除了用户名和密码哈希剩下的全是密码策略最近修改时间、最短使用天数、最长有效期、警告天数、宽限天数、失效日期等。/etc/shadow的权限往往非常严通常是600甚至000只有root能读写这是保护密码哈希的第一道防线。日常检查有个小技巧怀疑系统里多了来路不明的账号最快的办法是看/etc/passwd里哪些UID是0以及哪些账号的Shell不是nologin。正常系统里UID 0只有root冒出第二个基本可以认为被入侵了。同理awk -F: ($7 ! /sbin/nologin $7 ! /bin/false){print $1} /etc/passwd这条组合能快速列出所有允许登录的账号每次安全巡检我都会跑一遍。1.3 文件权限的底层模型文件权限的基础模型是三类身份、三个动作。三类身份是属主user、属组group、其他others三个动作是读r4、写w2、执行x1。数值权限就是这几个数字相加rwx7rw-6r-x5-wx3。但有一个非常容易被忽略的差异r、w、x在文件和在目录上含义完全不同。对文件来说r表示能读内容w表示能改内容x表示能把它当作程序执行。对目录来说r表示能列出目录里的文件名w表示能在目录里新建、删除、重命名文件x表示能穿过目录访问里面的文件——也就是所谓进入目录的权限。举个例子你去访问/a/b/c.txt需要/a、/a/b上至少都有x权限否则即使c.txt的权限是777你也进不到那一步。这正是很多文件权限明明777却还是无权限问题的根源问题往往出在上级目录缺少x。用namei -l /a/b/c.txt可以一次看到全路径每一级的权限排查这类问题比一级级 ls 快得多。另外你看到的drwxr-xr-x里的第一个d表示目录还有l表示软链接。软链接的权限本身没有实际意义真正起作用的是它指向的目标文件的权限。这就是为什么你给某个软链接chmod半天没效果改的还是目标文件。2. 账号管理的日常实操2.1 创建用户useradd背后的默认值创建用户的标准命令是useradd但它背后的默认值才是重点。直接useradd alice在很多发行版上并不会创建家目录也不会为你设置密码新手常常踩账号建了但登录不了的坑。实际工作中我一般用这样的组合useradd -m -s /bin/bash -c Project Member -G wheel alice逐个拆开看-m创建家目录-s /bin/bash指定登录Shell-c填备注-G wheel把用户加进管理组。如果不指定-u系统会从当前可用的最小UID通常1000之上自动分配不指定-g会创建一个和用户名同名的组作为主组。这里有个现象每个用户一个同名前缀的私有主组这是不少发行版的默认策略。好处是用户之间互不干扰新建文件默认属于自己这个组坏处是搞协作时每个文件还得额外chgrp到公共组麻烦。所以设计协作目录时我习惯显式指定主组让团队所有成员都归属同一个公共组后面第五节会给出完整方案。生产环境创建的服务账号通常跟普通用户不同不建家目录。比如给某应用建一个运行账号useradd -r -s /sbin/nologin -d /var/lib/appsvc appsvc-r表示创建系统账号UID从系统号段分配-s /sbin/nologin彻底堵死登录通道-d指定它的工作目录。这样这个账号只能用来跑进程密码都不用设登录通道直接被封死。2.2 改与删usermod和userdel创建只是开始日常改动更多。改用户用usermod参数基本和useradd呼应。把某人的Shell改成zsh、家目录挪走、锁定账号、设置到期时间都能用一条命令搞定usermod -s /bin/zsh alice usermod -d /home/newhome -m alice usermod -e 2025-12-31 bob # 账号到期 usermod -L alice # 锁定等价于在shadow密码前加! usermod -U alice # 解锁-L和-U锁定账号的原理是在/etc/shadow的密码哈希前加或去掉感叹号。这个细节有实际意义锁账号不像把密码整个清空锁完还能无损解锁临时让某位同学停摆非常方便解封的时候也不会出现密码忘了还要重置的麻烦。删除用户是个要谨慎的动作userdel alice userdel -r alice # 连家目录和邮件池一起删危险之处在于如果某人之前创建过文件而这些文件没被人接走那它们仍然由那个UID所有。一旦之后新用户恰好分配了这个UID这些无主文件就会自动变成新用户的文件数据权限就乱套了。所以删用户之前我习惯用find / -uid 旧UID -ls把所有遗留文件统计一遍确认没人要了再动手。2.3 密码策略passwd与chage密码管理不只是passwd alice改个密码那么简单。真正要管的是密码的生命周期。chage就是管这事的chage -M 90 -m 7 -W 7 alice chage -E 2025-06-30 alice chage -l alice-M 90是90天必须换一次-m 7是最少用7天才能再改-W 7是到期前7天开始警告。设置完之后chage -l能看到完整策略非常适合在季度末给账号做体检。如果你看到某个账号的密码过期字段是never而它又是一个长期不用的遗留账号那就要警惕了——这种账号往往是安全审计里最先被标红的目标。还有一批人习惯用echo 123456 | passwd --stdin alice在脚本里批量改密。这个写法在新版工具链里越来越不被待见因为它会出现在进程列表中别人ps一下就能看到密码明文。更稳妥的批量做法是用chpasswdecho alice:密码内容 | chpasswd另外系统自带的passwd命令在语法上会检查密码强度太简单的会被拒绝。如果你用root给用户改密它一般只会提醒但不会硬拦真正强制的强度策略要靠PAM的pam_pwquality模块第四节会提一句。2.4 组的管理主组与附加组组的管理命令和用户高度对称groupadd建组groupmod改组的GID和组名groupdel删组。这里真正需要理解的是主组和附加组的概念差异。主组在/etc/passwd里有记录用户创建文件默认属于主组附加组写在/etc/group的用户列表里决定你能访问哪些共享资源。给用户加组有两条路usermod -aG projdev alice # 推荐-a表示追加 gpasswd -a alice projdev注意usermod -G如果不带-a会把用户身上其他组全部替换掉。我见过有人本来在wheel组里想临时加个项目组少写了个-a结果瞬间丧失管理员权限场面一度非常尴尬。所以凡是追求追加效果务必用-aG这是命令行的肌肉记忆。组要被当前登录的会话感知到一般需要重新登录。等不及的话可以用newgrp 组名切换或者sg 组名 -c 命令临时用某组身份执行一条命令这些都是排查怎么加了组还是没权限时最常用的手段。3. 文件权限的底层逻辑与操作3.1 rwx对文件和目录的意义第一节已经初步区分过rwx在文件与目录上的差异这里展开并补充一个最容易被误解的目录的写权限不等于能改文件内容它控制的是能不能在这个目录里增删改条目。目录有w就允许你删除和重命名其中任意条目这跟文件属主是谁无关除非目录上设置了防删的粘滞位。这就是为什么共享目录几乎必须搭配粘滞位使用第五节会落地。对文件的x来说还有个细节x只是允许执行能不能真正跑起来还要看文件头部的地址格式对不对。对Shell脚本而言除了执行权限脚本本身还要有可读权限因为解释器要读脚本文本这也是脚本常见权限rwxr-xr-x而不是只有x的原因。另一个常见的认知盲区是进程的权限不是登录用户的完整权限而是有效权限。普通用户执行带SUID的程序进程有效UID会变成文件属主。最典型的就是passwd这个改密程序它的属主是root文件模式位里有-rwsr-xr-x中那个s普通用户执行它时以root身份去写/etc/shadow改完密码进程权限立刻回落。没有SUID的话普通用户根本碰不到shadow文件也就没法改自己的密码。3.2 chmod、chown和chgrp的正确姿势修改权限chmod有两种写法我都用场合不同chmod ux,g-w,or script.sh # 符号模式精确到单个动作 chmod 750 script.sh # 数值模式整体设定 chmod -R 750 /data/proj # 递归慎用符号模式的妙处在于它只动你指定的位其他位保持不变数值模式则是一次性清零重设。如果只想给某文件加上组写权限chmod gw file比chmod 775 file安全得多——后者会把其他人的权限也一并改写。我的习惯是精细改动用符号模式整体规范化用数值模式。改属主用chown它同时能改属组chown alice:projdev /data/proj/docs chown -R alice:projdev /data/proj/docschgrp只在单纯改属组的场景用到更多时候我用chown :组名这个省略属主的写法一行搞定。递归参数-R是最大的双刃剑遇到符号链接时有些版本的chown默认会改链接本身而不是目标行为略有差异递归操作前最好先ls -l看一下链接结构别把整棵目录树的所有权改歪了。注意千万别在远端服务器上随手执行chown -R alice /这类命令。一旦写错路径整个系统的文件属主全部错乱连sudo都救不回只能靠备份重来。我自己的铁律是递归改权限之前先用ls -ld确认路径确实是预期目录命令里的路径写成绝对路径杜绝手滑。3.3 特殊权限位SUID、SGID与Sticky普通rwx之外还有三组特殊位对应数值是4、2、1加在权限组开头。它们经常被忽略但在共享目录和安全加固里又无处不在。SUIDsetuid值为4显示为属主执行位上的s前面提过核心是执行时把有效UID变成文件属主。整个系统里SUID文件越少越安全可以用find / -perm -4000 -ls定期盘点看到可疑的新增SUID文件就要检查是不是被人动了手脚。SGIDsetgid值为2显示为属组执行位上的s有两种场景作为文件位执行时有效GID变成属组作为目录位所有在目录里新建的子文件和子目录都会自动继承目录的属组。后者是共享目录的神器只要把/data/proj设成chmod 2770不管谁在里面创建文件文件的属组都会自动变成projdev不用每个人每次手动chgrp。第五节的核心方案就是靠这一位撑起来的。Sticky粘滞位值为1显示为其他用户执行位上的t只对目录有意义。设置后目录里任何条目只有文件属主、目录属主或root能删除改名其他人就算有目录写权限也删不了别人的文件。/tmp之所以人人都能建文件又互相删不了对方的东西靠的就是drwxrwxrwt里的t。设置写法chmod us /usr/local/bin/tool # SUID chmod gs /data/proj # SGID chmod t /data/proj/uploads # Sticky chmod 4755 /usr/local/bin/tool # 数值形式 chmod 2770 /data/proj chmod 1770 /data/proj/uploads3.4 umask每个新文件都带着模具出生你有没有好奇过为什么新建文件默认是644、新建目录默认是755这背后是内核在创建完成之后马上按umask对权限做减法。umask是个掩码含义是这些位我要去掉。常见发行版默认umask是022对应的逻辑是文件初始权限666减去022得644目录初始权限777减去022得755。注意普通文件默认拿不到x是因为创建文件的初始权限是666而不是777执行位要不回来。umask # 查看当前值通常是0022 umask 077 # 临时设置新文件变成600新目录变成700把umask设成077会让新建的文件只能属主读写这在处理敏感数据的目录里很实用。更高安全要求的地方会设027意思是组内成员只保留r和x不给组写。如果你发现团队里新建的脚本总是不带执行位或者共享目录里新文件组内成员没法改先看一眼umask它经常比chmod更早地决定了文件命运。umask的修改要写进用户的Shell初始化文件比如.bashrc或.profile才会对登录会话持久生效很多人临时改了umask以为生效了重开一个终端发现又变回022其实就是没落盘。4. 更细粒度的控制ACL、sudo与PAM4.1 ACL给具体某个人开一扇门传统权限模型最大的尴尬是组外人进不来组内人权限都一样。假设有个目录属于projdev组你想让另一个部门的人只读这一个目录又不想把他塞进组里这时ACL访问控制列表就派上用场了。ACL允许你绕过属主/属组/其他的三分法直接为指定用户或用户组分配权限。setfacl -m u:bob:rx /data/proj/docs # 给bob读和进入的权限 setfacl -R -m u:bob:rx /data/proj/docs # 递归应用 setfacl -d -m u:bob:rx /data/proj/docs # 设置默认ACL影响以后新建的文件 getfacl /data/proj/docs # 查看ACL带ACL的文件在ls -l里权限位末尾会出现号例如-rw-rw-r--。看到这个标记就说明文件上还挂着ACL规则必须用getfacl才能看到全貌。ACL里有个字段叫mask它表示所有命名用户、命名组、属组权限的上限。执行setfacl -m u:bob:rx时系统会自动把mask更新成当前所有ACL权限的并集。如果你之后用chmod收窄了组权限mask会被一并修改ACL里名义上的rwx就可能被mask拦截。遇到ACL明明给了rwx却写不进去的怪事第一反应就是看mask别问我是怎么知道的。取消一条ACL用setfacl -x u:bob 文件清空全部ACL用setfacl -b 文件后一个在同别人交接目录时很常用。4.2 sudo把root的钥匙切成碎片给用户直接暴露root密码是最不推荐的姿势。通用做法是让用户通过sudo按需执行管理命令。sudo的配置文件是/etc/sudoers修改必须走visudo它会在保存前做语法检查避免你写错一行导致整个sudo服务报废。最基本的一条规则是把某个用户组整体授权%wheel ALL(ALL) ALL意思是wheel组里的成员可以在任意主机上以任意用户身份执行任意命令。范围太宽泛了我更推荐收敛到具体命令比如只允许alice重启某服务alice ALL(root) /usr/bin/systemctl restart myservice还可以用Cmnd_Alias把一组命令打包授权比如让某运维组只能管理服务状态而不能改账号Cmnd_Alias SERVICE_CMD /usr/bin/systemctl list-units, /usr/bin/systemctl status %ops ALL(root) SERVICE_CMDsudo常用的运行时参数也要掌握sudo -l查看当前账号被授权了哪些命令sudo -u bob id以其他用户身份执行sudo su -是很多人获取root交互Shell的做法但管理严格的团队会禁掉这行。另外sudo默认有5分钟时间戳缓存用sudo -k立刻失效客户端密码长时间挂着不用时记得锁上。配置sudoers时有个经典翻车点把账号加进提权组后该账号的sudo并不能立刻生效需要重新登录一次。而且如果你的规则写错可以在测试机上先用visudo -c检查配置文件再小心地用sudo -l验证授权结果避免在生产上把自己锁在管理门外。4.3 PAM认证流程的总闸门PAM可插拔认证模块是账号认证的中枢框架。每一次登录、sudo、su、修改密码背后都有一串PAM模块在按顺序做检查。配置文件分布在/etc/pam.d/下常见的有login、sshd、sudo、passwd等服务名对应文件名。我不打算把每个模块参数都抄一遍只讲两个最实用的场景。第一是登录失败锁定。在认证链里配置pam_faillock可以让同一个用户名连续失败几次后锁定一段时间。具体配置因发行版而异核心是deny阈值和unlock_time两个参数。这能有效减缓针对SSH的暴力猜测至少让脚本刷密码的速率显着下降。第二是密码强度。pam_pwquality模块可以要求新密码最小长度、包含不同类型字符、不能与用户名相同。配好之后即使root强制改密策略也会按同样的标准校验而不是简单放行。PAM的排查也有套路登录失败时先看/var/log/auth.log或/var/log/secure里面每一条PAM报错都会有具体模块名。我用grep在这个日志里过滤出pam_关键字十有八九能直接定位问题。另一个常见坑是手动改PAM配置时把某行模块路径写错导致sshd起不来——改之前备份改完之后先开一个窗口保持SSH连接别断再测试新登录。修改认证配置前务必保留一个可用的登录通道这是保住生产环境的保命玩法。5. 实战从头搭建一个多人协作环境5.1 场景设计与需求拆解我直接用一个真实工作场景来说明整套体系怎么落地。某小型团队要搭建一台项目服务器需求列下来其实很典型三名成员alice、bob、carol共用一个项目目录都要能读写。目录里再分一个/data/proj/uploads用来收大家提交的产物任何人可以放文件但不能删别人的。alice是小组负责人能管理目录结构还负责重启项目服务。应用本身需要一个独立的系统账号来运行这个账号不能登录。翻译成权限设计就是一个公共组projdev承载三个人的协作项目根目录开SGID保证新文件自动继承公共组uploads目录补一个Sticky位防止互删alice走sudo专项授权应用账号用nologin系统账号独立隔离。5.2 完整操作过程第一步建组和用户groupadd -g 2000 projdev useradd -m -s /bin/bash -c Project Member -g projdev alice useradd -m -s /bin/bash -c Project Member -g projdev bob useradd -m -s /bin/bash -c Project Member -g projdev carol echo Bks#23Ej9 | chpasswd这里我把三人的主组直接指定为projdev省去后面大量chown。密码用chpasswd批量搞定避免在进程列表里暴露明文。第二步建目录并赋予权限mkdir -p /data/proj/uploads chown root:projdev /data/proj chmod 2770 /data/proj chown root:projdev /data/proj/uploads chmod 1770 /data/proj/uploads2770里的2就是SGID目录内新文件自动继承projdev组1770里的1是Sticky防止成员互相删文件。两个目录都做到了组内全读写、组外一律不可见这是共享数据的基本安全底线。第三步给应用建独立运行账号useradd -r -s /sbin/nologin -d /var/lib/appsvc appsvc chown -R appsvc:appsvc /var/lib/appsvc运行账号和协作账号之间做好隔离即使某应用被攻破攻击者也只能拿到这个受限账号的权限没法直接进入团队共享目录。第四步用visudo单独给alice授权alice ALL(root) /usr/bin/systemctl restart appservice只授权这一条命令alice能完成她负责的重启服务动作却无权改账号、改密码或者动其他系统配置。5.3 验证、收尾与安全基线搭建完成后不能直接宣布完工要逐项验证id alice # 确认主组是projdev ls -ld /data/proj # 确认drwxrws--- ls -ld /data/proj/uploads # 确认drwxrws--T 或 drwxrwxrwt 等实现 su - alice -c touch /data/proj/test.txt ls -l /data/proj/test.txt # 看属组是否自动变成projdev su - bob -c rm /data/proj/test.txt # 验证bob能不能删除alice的文件如果test.txt的属组是projdev且bob删不掉属于alice的文件说明SGID和Sticky都正常生效。这一步很多人会跳过但真出问题的时候返工成本会比验证成本高出一个量级。之后还要做一轮安全基线检查确认SSH的root远程登录被禁用grep nologin /etc/passwd检查所有服务账号是否都使用了nologinfind / -perm -4000 -ls盘点SUID文件chage -l抽查密码策略。这一套动作做完这个协作环境才算真正交付。6. 常见问题与排查技巧实录6.1 高频问题速查表我把自己和周围人踩过的坑汇总成一张速查表按频率排序现象最常见原因排查命令文件权限是777还是Permission denied上级目录缺x权限namei -l 完整路径加了某权限组却还是无权限组信息未刷新需重新登录id; newgrp 组名新文件在共享目录里属组不对目录没设SGIDls -ld 目录明明在共享组里却改不了共享文件目录里有独立属主的子目录getfacl; ls -l删不掉共享目录里别人的文件目录缺Sticky位ls -ld 目录sudo执行后还是无权限提权组信息未生效sudo -l; 重新登录用户登录后没有家目录useradd忘记-mls -ld /home/用户这张表不能解决所有问题但能覆盖日常运维里八成以上的权限报错。遇到没列出的情况先做最小复现用一个测试账号、一个测试目录一步步缩小范围比直接翻日志高效得多。搞权限问题最怕的是头痛医头看到一个Permission denied就立刻去chmod而不去看整个路径和身份链路。6.2 排查思路与工具我的排查流程基本是固定的三条路。第一条路从身份入手问题账号到底在哪些组里、有效UID是谁用id和sudo -l马上见分晓。第二条路从路径入手用namei -l把从根到目标文件的每一级目录权限都列出来权限不足的位置立刻暴露。第三条路从日志入手登录认证类问题看auth日志sudo问题看sudo日志服务起不来再看对应服务的日志。三个辅助工具值得常驻stat能看文件完整的mode、UID、GID和ACL标记getfacl看ACL细节find / -uid 数字 -ls在删用户前后找遗留文件。排查速度最快的是养成三步定位习惯先确认身份再确认路径各级权限最后查日志确认是认证失败还是授权失败。6.3 用血泪换来的几条习惯最后分享几条我反复踩坑后沉淀下来的操作习惯。第一任何递归改权限之前先ls -ld看清路径再深吸一口气。一个字符的失误就可能把整个系统权限搅乱我自己就曾因为路径多敲了一个点把备份目录的属主全改没了最后靠备份恢复才救回来。现在凡是要递归的操作我都先把命令写在草稿上检查一遍再粘贴执行。第二管理类操作尽量在单独窗口里留一个已认证的root会话。不管你是用普通用户加sudo还是直接root在调整PAM、sudo配置或密码策略前一定要先确认还有一个能用的登录通道免得配置一生效自己先被锁在外面。这个问题几乎每个运维都经历过一次区别只是代价大小。第三给用户建账号的默认Shell如果不是特别需求一律nologin。能用该账号登录的人越少被爆破或误操作的概率越低。真正的业务用户单独开会话允许。第四定期做权限审计。我的习惯是每季度跑一遍检查UID为0的账号、列一下所有带登录Shell的账号、盘点SUID和SGID文件、抽查密码有效期。这套动作花不了半小时但能让你及时发现谁开了个不该开的账号哪个目录多挂了个ACL之类的问题。账号和权限管理说到底没有太多玄学就是把每个命令背后的模型理解透再养成一套自己的动手习惯。我第一次上手那会儿也曾经凭感觉乱敲命令觉得只要眼睛看到权限对就行了后来翻了车才意识到系统的判断标准永远是那几个数字和文件位而不是你以为的样子。这行做得越久越明白把最基础的东西做扎实比追求花哨技巧值钱得多。