403错误本质是Web进程用户（如www-data）对CSS文件或其任意父目录缺少执行（x）或读（r）权限；需逐级检查ls -ld /var/www/html、/var/www/html/css及ls -l /var/www/html/css/style.css权限，并确认用户属主匹配，否则即使路径正确也会拒绝访问。
403 错误不是路径写错了，而是服务器“找到了文件，但不让你读”——核心是 www-data（或 _www、nginx）这类 Web 进程用户对 CSS 文件或其**任意一级父目录**缺少执行（x）或读（r）权限。
检查目录与文件的实际权限是否允许 Web 用户访问
必须逐级验证，缺一不可：
-
ls -ld /var/www/html：根目录至少要有drwxr-xr-x（即其他用户有x），否则进程连入口都没有 -
ls -ld /var/www/html/css：CSS 所在目录同样需要其他用户有x权限（drwxr-xr-x或drwxr-x--x） -
ls -l /var/www/html/css/style.css：文件本身需其他用户有r权限（-rw-r--r--即 644 足够，不需要x） - 若输出中第三列是
root、第四列是root，而 Web 进程以www-data身份运行，则即使权限是 644，也会 403 —— 因为www-data不属于root组，也不等于root
Nginx 配置里漏掉 user 指令是高频原因
很多 Nginx 安装默认用 nobody 启动，但它几乎不可能有权限读你的项目文件。必须显式声明：
- 打开
/etc/nginx/nginx.conf（Linux）或/usr/local/etc/nginx/nginx.conf（Mac） - 确认第一行存在类似
user www-data;或user _www staff;；若缺失或注释掉了，就补上并重启：sudo systemctl restart nginx - 别用
user root;—— 虽然能绕过权限问题，但严重违反安全原则，Nginx 官方明确禁止
Apache 下 .htaccess 可能静默拦截 CSS 请求
哪怕文件权限和路径都对，.htaccess 里的规则也可能把 .css 当成敏感资源拦掉：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
立即学习“前端免费学习笔记（深入）”；
- 检查是否有
Deny from all或Require all denied且没配白名单 - 常见陷阱：
<Directory "/var/www/html/css"> Require all denied </Directory>—— 这会直接封死整个目录 - 更安全的写法是显式放行静态资源：
<FilesMatch "\.(css|js|png|jpg)$"> Require all granted </FilesMatch> - 临时验证：重命名
.htaccess为.htaccess.bak，刷新页面看 CSS 是否恢复
浏览器 Network 面板里看到 403 就别查路径了
一旦确认状态码是 403（不是 404），说明请求已抵达服务器、路径解析成功、文件存在 —— 此时所有前端路径调整、<link> 标签修改、缓存清理都是徒劳的。
真正要盯住的是：Web 进程用户能否 cd 进目录、能否 cat 出文件内容。用它实际身份测试最可靠：sudo -u www-data cat /var/www/html/css/style.css —— 如果报 Permission denied，就不用再猜了，就是权限链断在某一级。
