尧图网站建设 
简介一份面向Web开发初学者的PDF学习参考系统梳理网站建设从概念到实践所需的基础知识。内容从域名、HTTP、IP地址、宽带与带宽等基础概念切入阐释移动互联网、3G等现代网站所处的技术环境进而概述Web发展历程及TCP/IP等计算机网络与互联网理论基础帮助零基础读者建立整体认知框架。核心部分围绕HTML及HTML5语义化标签、CSS选择器与盒模型及浮动定位、JavaScript语法与事件处理和DOM操作展开并补充服务器管理、数据库操作、SEO优化、用户体验设计等综合技能覆盖早期个人建站者从策划、开发到维护运营所需兼任的多项职责。整份资源为单个PDF文件大小仅约15KB内容精炼便携、便于随时查阅目前已有89人浏览学习适合刚接触Web开发、希望快速厘清学习路线与技能地图的初学者。1. “Web基础知识和技术指导”到底该怎么读把参考 PDF 变成施工图这份参考 PDF几乎每个从业者都存过。可现实是真正让你留在行业的从来不是“读完”而是能复现、能排查、能交付。我给新人的建议是把这个标题当成一张施工图而不是百科词条——把 Web 拆成“一个 URL 怎么变成页面”“一个本地工程怎么跑起来”“一个真实服务怎么上线”三条线再补上安全与排查才叫有技术指导价值。这篇文章就按这条线展开从前端三件套到后端接口、从浏览器调试到服务器部署最后落到调试技巧和坑点。适合刚入行的 web 前端开发、转岗的后端工程师以及要搭企业级 Web 开发培训的团队。我不背定义只看现象、抓包、改配置、验证结果。与其花时间找“后悔药”不如用这份基础清单亲手把 Web 请求拆一遍。2. 从 URL 到页面用 curl、DNS 与端口拆开网络黑匣子很多 Web 项目上午还能访问下午就“玄学”了。所谓玄学大概率卡在网络层域名解析走错了、端口被占、缓存没生效。下面用三个可复现动作把它讲透后面所有层的排查都能踩在同一条路径上。2.1 用 curl -v 看完一次 HTTP 请求先不看浏览器直接在命令行里发一次请求。这是观察网络基础最快的方式任何机器上只要有 curl 就能做。curl -v --max-time 10 http://example.com-v是 verbose把 TCP 连接、请求头、响应头全部打印出来--max-time 10是兜底避免 DNS 卡死时脚本一直挂在那里。一般输出里能看到这几段关键信息* Connected to example.com (93.184.216.34) port 80 GET / HTTP/1.1 Host: example.com User-Agent: curl/... HTTP/1.1 200 OK Content-Type: text/html第一行证明 TCP 已连上DNS 成功解析出 IP开头的是你发给服务器的请求头开头的是服务器返回的响应头。这正好对应一次 HTTP 请求的四件事连接要通、路径要对、请求头要全、响应头要懂。很多 Web 前端开发第一次在浏览器里看到报错就慌其实在 curl 里能看到同样的问题。再看 HTTPS 请求重点看证书协商那一段curl -v https://www.baidu.com -o /dev/null 21 | head -40-o /dev/null表示丢弃响应体只看过程21 | head -40是把大量输出截断到前 40 行。这里你会看到 TLS 握手产生的证书链、加密套件等。如果证书过期、域名不匹配curl 会在这一层直接报错而浏览器只是安静地拦下页面。所以排查“页面打不开”之前先用 curl 确认握手是否正常能省一半时间。最后是带请求体的 POST。后端接口联调时很多参数错误其实是 Content-Type 没对上。curl -i -X POST http://127.0.0.1:3000/api/hello \ -H Content-Type: application/json \ -d {name:web}-i会把响应头也打出来确认服务器返回的 Content-Type 是不是application/json-H加自定请求头-d传原始 body。这里要记住一个原则HTTP 是用请求头声明“我发的是什么、我要什么”用状态码表达“结果怎么样”。你后面写的所有代码本质上都是在伺候这两个字段。2.2 DNS 解析与本机端口Web 项目连接故障的第一检查单如果 curl 显示Could not resolve host说明域名解析失败如果显示Connection refused说明目标机器的端口没有进程在听。先跑下面三条命令定位nslookup www.baidu.com cat /etc/hosts ss -lntpnslookup查的是域名当前解析到哪个 IPcat /etc/hosts看本机有没有写死 IP 映射。hosts 文件的优先级高于 DNS 解析很多测试环境的“灵异问题”就是 hosts 里残留了旧 IP。ss -lntp列出本机正在监听的 TCP 端口和对应进程适合排查端口占用。Windows 上对应的两条命令是ipconfig /flushdns netstat -ano | findstr :8080ipconfig /flushdns清空系统 DNS 缓存netstat -ano里的最后一列是 PID拿到后用任务管理器按 PID 找进程即可。这里有一个职场新人容易踩的坑改了域名解析记录本地怎么访问都是旧服务器。原因往往是浏览器缓存、系统缓存、路由器缓存三层叠加。最直接的办法是换一台干净网络的机器验证而不是反复刷新。还有一个经典场景IDEA 2024 创建 Web 项目时内置容器默认监听 8080。你前一个项目没关干净第二个项目启动就报Address already in use。先执行lsof -i :8080看谁占着端口再决定是杀进程还是换 8081。端口不是越多越好越清晰越好。2.3 HTTP 无状态但 Header 驱动登录态到底存哪里HTTP 协议本身不记人。同一个用户连续发两个请求服务器没有机制知道它们来自同一浏览器这就叫无状态。真正把用户串起来的是 Cookie。用 curl 可以完整演一遍登录态的产生和回放# 第一次请求把服务端下发的 Set-Cookie 保存到文件 curl -v -c cookies.txt http://127.0.0.1:3000/api/login # 第二次请求把保存的 Cookie 原样带回 curl -v -b cookies.txt http://127.0.0.1:3000/api/profile-c把响应头里的 Cookie 写入文件-b把文件里的 Cookie 作为请求头发出去。服务端的登录接口一旦验证通过就会在响应头里放Set-Cookie: sessionxxxx浏览器下次请求自动带上Cookie: sessionxxxx服务器靠这个识别身份。这里要分清楚浏览器侧的三种存储存储方式是否随请求自动发送典型用途Cookie是登录态、会话标识localStorage否用户偏好、长期缓存sessionStorage否单标签临时数据很多新手把 token 放 localStorage然后接口每次都要手动拼。能不能用能但刷新页面后你需要自己写初始化逻辑去取。Cookie 的好处是自动携带代价是要处理跨域、SameSite、过期时间等属性。理解这两行 curl再去看后端框架里的 Session、JWT你会瞬间明白它们只是换了一种存放和校验身份的方式底层的坑还是 HTTP Header 那一套。3. 搭建前端工程手写三件套再用 Vite 起一个 Vue 3 Web 项目我建议前端基础必须从“不依赖框架”开始。跳过这一步直接学框架碰到样式不生效、接口跨域、路由 404你根本不知道是框架的问题还是浏览器本身的问题。下面把两条路径都走一遍先用手写三件套理解渲染再用 Vue 3 工程化进入真实业务最后把 Java Web、Go Web 的对照关系讲清楚。3.1 先手写 HTML/CSS/JS理解浏览器从文本到页面的过程新建一个index.html复制下面这段最小页面!DOCTYPE html html langzh-CN head meta charsetUTF-8 title最小 Web 页面/title style body { font-family: system-ui; margin: 40px; } p { color: #333; } /style /head body p idmsg加载中.../p script fetch(http://localhost:3000/api/hello) .then(r r.json()) .then(d { document.getElementById(msg).textContent d.message }) .catch(e { document.getElementById(msg).textContent 接口失败 e.message }) /script /body /html这段代码做了三件事HTML 定义结构CSS 定义外观JavaScript 用fetch请求接口并把结果写进页面。注意script放在 body 末尾因为浏览器遇到script会暂停解析 HTML先去下载和执行脚本。如果脚本放在 head 里页面会出现白屏这是新手最容易忽略的渲染阻塞点。实践里常用script defer让脚本延后执行既不影响 DOM 解析又能保证元素已经存在。把这文件直接拖进浏览器你会发现它没有样式、甚至接口报错。原因很简单浏览器打开本地文件时协议是file://很多功能和 CORS 策略对这种方式不友好。正确做法是起一个本地静态服务下一步的 Vite 会解决这个问题。如果你想把这个页面打印成 PDF按 CtrlP 时打印预览也要走一遍完整渲染如果预览空白优先怀疑是不是有浏览器插件屏蔽了打印弹窗而不是页面代码本身。3.2 Vite 与 Vue.js Web API用两条命令得到企业级前端骨架手写页面理解原理后就该进入工程化了。现在的 Web 项目很少有纯三件套Vue、React 这类框架配合 Vite 已经是企业级 Web 开发的主流底座。用 Vite 起一个 Vue 3 项目npm create vitelatest my-web -- --template vue cd my-web npm install npm run dev第一条命令创建名为my-web的 Vue 模板工程npm install安装依赖npm run dev启动开发服务器默认在http://localhost:5173。生成的结构里src/main.js是入口src/App.vue是根组件src/components放可复用组件。真实业务到后面还会拆出src/api统一管接口、src/router管路由、src/store管状态。脚手架可以生成目录但排查能力必须自己练。接下来把刚才的 fetch 逻辑放进一个组件里完成一次 Vue.js Web API 对接script setup import { ref, onMounted } from vue const msg ref(加载中...) onMounted(async () { try { const res await fetch(http://localhost:3000/api/hello) msg.value (await res.json()).message } catch (e) { msg.value 接口失败 e.message } }) /script template p{{ msg }}/p /templatemsg是响应式变量模板里用双花括号绑定onMounted是组件挂载完成后触发。这段代码和 3.1 的 fetch 本质没有区别只是把 DOM 操作交给 Vue 完成。如果你在浏览器里看到接口失败去看 Network 面板大概率是 CORS 或端口没通下一章会专门讲。3.3 换语言不换思路Java Web 与 Go Web 的相同骨架前端会了后端不要急着选语言。浏览器和服务器之间只认 HTTPJava、Go、Node 写出来的接口对前端来说没有任何区别。以 IDEA 2024 创建 Web 项目为例Spring Boot 里只需一个类就能完成上面接口的功能RestController public class HelloController { GetMapping(/api/hello) public MapString, String hello() { return Map.of(message, 你好Web 基础); } }Go Web 编程里同样简练func main() { http.HandleFunc(/api/hello, func(w http.ResponseWriter, r *http.Request) { w.Header().Set(Content-Type, application/json; charsetutf-8) fmt.Fprintln(w, {message:你好Web 基础}) }) log.Fatal(http.ListenAndServe(:8080, nil)) }看到没有监听端口、读请求路径、设置响应头、写回 body四种语言四个步骤。Java 用注解Go 用函数Node 用回调但底层全是 HTTP 协议。基础一旦立住你在这些技术栈之间切换只是换语法不换思路。这也是我把这份“技术指导”定位成通用地基而不是某一种语言手册的原因。4. 把接口和页面一起跑通Node 起接口Nginx 做静态托管前端开发时跑在 5173接口在 3000这是“开发模式”。线上不能这么裸奔要把静态页面放到标准 Web 服务器里接口也要能扛住进程退出。这一章的目标是走完从npm run build到 Nginx 静态托管、再到进程守护的完整路径。4.1 Node 内置模块起一个零依赖接口不看 Express用 Node 原生http模块就能把接口跑起来。代码越少越容易看清 Web 原理const http require(http) const server http.createServer((req, res) { // 开发阶段放开跨域生产环境必须收紧成自己的域名 res.setHeader(Access-Control-Allow-Origin, *) res.setHeader(Access-Control-Allow-Methods, GET,POST,OPTIONS) res.setHeader(Access-Control-Allow-Headers, Content-Type) if (req.method OPTIONS) { res.writeHead(204) res.end() return } if (req.url /api/hello) { res.writeHead(200, { Content-Type: application/json; charsetutf-8 }) res.end(JSON.stringify({ message: 你好Web 基础 })) return } res.writeHead(404, { Content-Type: text/plain; charsetutf-8 }) res.end(not found) }) server.listen(3000, () { console.log(接口已启动http://localhost:3000) })保存为server.js执行node server.js另开一个终端验证curl -i http://localhost:3000/api/hello你会看到状态码 200、Content-Type: application/json; charsetutf-8和响应 body。代码里的Access-Control-Allow-Origin就是 CORS 的核心允许哪个源访问接口。本地开发图省事用*但生产环境一定写死成你的域名否则任何网页都能向你的接口发请求这是最低门槛的 web 安全事故。OPTIONS分支处理的是浏览器跨域预检前端发application/json这类非简单请求时浏览器会先问服务器“你允不允许”服务器必须回答 204。4.2 Nginx 静态托管与 web 服务器安全最小可上线配置前端执行npm run build后产物在dist/目录。把dist/里的文件放到服务器/var/www/my-web下再用 Nginx 托管。下面是一个能用的最小配置server { listen 80; server_name example.com; root /var/www/my-web; index index.html; gzip on; gzip_types text/plain text/css application/javascript application/json; location / { try_files $uri $uri/ /index.html; } location ~* \.(js|css|png|jpg|jpg|jpeg|gif|svg|woff2)$ { expires 7d; add_header Cache-Control public, no-transform; } }root指定静态文件根目录index index.html表示访问根路径时默认返回index.htmltry_files $uri $uri/ /index.html这句最重要当 URL 路径不存在时把请求回退到前端入口页面这样 Vue Router 的 history 模式刷新才不会 404。gzip相关指令把文本类资源压缩后再交给浏览器能明显减小传输体积。第二个 location 对图片、字体这类体积大又不太变的资源设置七天的浏览器缓存让二次打开更快。改完配置先验证再重载nginx -t systemctl reload nginxnginx -t只检查语法不实际生效systemctl reload会平滑重载配置不会中断现有连接。这两个命令一个用于防翻车一个用于发布。安全加固不要等上线后再做。在 server 块里加上这几行成本极低但能挡掉一批自动化扫描server_tokens off; autoindex off; add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always;server_tokens off隐藏 Nginx 版本号减少被针对性攻击的暴露面autoindex off禁止目录列表防止别人看到你的文件结构X-Content-Type-Options让浏览器不猜测文件类型降低脚本注入风险X-Frame-Options禁止页面被嵌进 iframe。这些都属于基础的 web 服务器安全配置加上之后再用漏洞扫描工具扫一遍告警会少一大截。HTTPS 证书的申请与续期常见做法是用 ACME 自动签发客户端它会自动修改 Nginx 配置并建立定时续期任务。证书没有任何“装完就结束”的说法你要盯的是续期任务有没有跑成功。4.3 进程守护与发布顺序别让接口在终端一关就消失开发时node server.js跑在前台CtrlC 就没了这在生产环境是不可接受的。用 systemd 把接口守护起来[Unit] Descriptionmy-web-api Afternetwork.target [Service] ExecStart/usr/bin/node /var/www/my-web/server.js Restartalways RestartSec3 [Install] WantedBymulti-user.targetRestartalways表示进程意外退出时自动拉起RestartSec3是重启前等三秒防止机器刚起来时环境还没就绪导致反复闪退。写完保存为/etc/systemd/system/my-web-api.service执行systemctl daemon-reload systemctl enable --now my-web-apidaemon-reload让 systemd 读取新配置enable --now设置开机自启并立即启动。发布顺序我的习惯是先npm run build生成新静态文件再替换 Nginx 目录最后 reload Nginx。如果接口逻辑也变了先重启 systemd 服务再 reload Nginx。顺序别反否则用户会先看到新页面打到旧接口上的中间态。防火墙层面对外只放开 80 和 4433000 端口只允许本机访问。这是部署一个新 Web 项目时最容易在最后一步漏掉的安全短板。4.4 开发模式的跨域问题先理解再绕过前端 5173、接口 3000两个端口天然跨域。我在本地调试时纠结过要不要直接改 Nginx 把端口收拢。后来想通了对于初学者就在双端口下把 CORS 配置跑通这是理解“同源策略”最好的现场。生产环境里让 Nginx 把/api开头的请求转发到 Node 端口的做法也很常见原理仍是“改路径、带 Host、放行响应头”等你把 CORS 这节弄懂那套配置就是看一眼就会的事。5. Web 基础避坑指南五个现场最容易翻车的排查清单下面五条都来自真实线上问题按现象、原因、解决三段写。对号入座最快也最适合把它贴到团队 Wiki 里当 Web 项目排查手册。5.1 端口被占用导致服务起不来现象npm run dev或node server.js启动后立刻报EADDRINUSE甚至页面一直转圈。报错里会带端口号最常见的是 3000、8080、5173。原因上一次运行的进程没退出或者有另一个程序抢占了端口。IDEA 2024 创建 Web 项目时前一个 Tomcat 没关干净下一个项目就会踩这个。解决先看端口被谁占用再决定杀进程还是换端口。# macOS / Linux lsof -i :3000 # Windows netstat -ano | findstr :3000拿到 PID 后执行kill -9 PID。如果这个端口是团队的公共约定不要为了省事随手换到别的端口把默认端口保留下来避免换到别的服务的端口上引发更大的事故。5.2 前端路由刷新就 404现象单页应用里点击跳转一切正常但按 F5 刷新后直接 404地址栏路径明明是对的。尤其是配了 Vue Router history 模式的项目几乎必踩。原因刷新时浏览器用真实路径请求服务器服务器发现没有这个文件就回 404。前端路由是给页面在内存里用的服务器不知道document。解决在 Nginx 里给 SPA 加一个回退让它重新加载 index.html。location / { try_files $uri $uri/ /index.html; }这句的含义是先找真实文件找不到就尝试目录再找不到就回退到/index.html由前端路由重新接管路径。加了之后刷新 404 基本绝迹。5.3 中文乱码和 favicon 一直请求失败现象页面中文变锟斤拷浏览器 Console 里favicon.ico一个 404日志里全是噪音。原因HTML 没有声明编码或后端响应头里的 Content-Type 没有带 charset。favicon 是浏览器默认行为项目没放图标文件就会反复请求。解决前端加meta charsetUTF-8后端在响应头里写明白res.writeHead(200, { Content-Type: text/html; charsetutf-8 })favicon 的解决不是删代码而是放一个favicon.ico到静态目录或用link relicon hrefdata:,告诉浏览器“我们没有图标别再造请求了”。出道最低成本的一个坑。5.4 接口请求被 CORS 拦下现象前端报blocked by CORS policy请求在 Network 面板里是红色但 curl 直接访问完全正常。原因你用了浏览器而浏览器在同源策略下发现了“前端 5173、接口 3000”不是同一个源。curl 没有源的概念所以它不会拦。解决在后端响应头里声明允许的来源不要在生产环境用*加凭证。res.setHeader(Access-Control-Allow-Origin, http://localhost:5173) res.setHeader(Access-Control-Allow-Credentials, true)如果要带 CookieAccess-Control-Allow-Origin 不能是*必须是具体源同时要打开 Allow-Credentials。开发环境你也可以让调试服务器把/api开头的请求统一转发到接口端口但这属于“绕过”理解 CORS 本身才是做 web 安全的前提。5.5 HTTPS 页面里混入 HTTP 资源现象页面能打开但图片不显示、接口请求被浏览器自动阻止Console 提示Mixed Content。原因你申请了 HTTPS 证书页面是https://但页面里引用的图片、脚本、接口地址还是写死的http://。浏览器为了防降级攻击直接不加载混合资源。解决把资源地址改成相对路径或协议自适应写法//cdn.example.com/js/app.js让浏览器用当前协议自动拼。更彻底的办法是在 Nginx 里加一个响应头add_header Content-Security-Policy upgrade-insecure-requests always;这行配置让浏览器把所有 HTTP 请求自动升级成 HTTPS。注意它只对页面内发起的请求生效如果 Nginx 后面的接口本身只监听 HTTP你还需要保证服务本身支持 HTTPS 访问。混合内容检查基本是 HTTPS 改造上线后的第一道鬼门关用这招能让你少不少发布会翻车的场面。6. 一个验证技巧60 秒用 Network 面板定位前端问题这一章分享一个我每天都会用的验证方法。遇到“页面好像不对”先别急着看代码打开浏览器开发者工具切到 Network 面板清空日志再手动触发一次出问题的操作。按下面四列依次读第一列是状态码。2xx 就算运输成功3xx 看它重定向到哪里4xx 是客户端问题5xx 基本是后端或网络链路故障。一个常见情形接口返回 304表示浏览器用了缓存如果你刚改了代码却看到 304强制刷新一次再判断。第二列是响应头里的 Content-Type。返回值是text/html前端却按 JSON 解析报错会非常隐蔽。先确认服务器发的是不是application/json再去纠结为什么data是空的。很多所谓的乱码和解析失败都是这一项没对齐。第三列是瀑布图里的等待时间。浏览器发起请求后大部分时间耗在 DNS、等待响应头和下载 body 三件事里。如果 TTFB 特别长问题基本在后端如果 TTFB 很短但下载时间很长通常是接口返回了大体积响应体。第四列是 Initiator它告诉你这次请求是哪个脚本发起的。找前端代码里的具体位置比在 Console 里瞎猜要快得多。我的习惯是每开发一个新功能顺手把功能涉及的请求看一遍状态和类型五分钟后你就对这套 Web 基础是否真的通了心里有数。这个习惯帮我挡掉过很多次评审现场页面打不开的翻车。希望帮到你。本文还有配套的精品资源点击获取 Web基础技术指导：从URL到页面部署的实战排查手册
简介一份面向Web开发初学者的PDF学习参考系统梳理网站建设从概念到实践所需的基础知识。内容从域名、HTTP、IP地址、宽带与带宽等基础概念切入阐释移动互联网、3G等现代网站所处的技术环境进而概述Web发展历程及TCP/IP等计算机网络与互联网理论基础帮助零基础读者建立整体认知框架。核心部分围绕HTML及HTML5语义化标签、CSS选择器与盒模型及浮动定位、JavaScript语法与事件处理和DOM操作展开并补充服务器管理、数据库操作、SEO优化、用户体验设计等综合技能覆盖早期个人建站者从策划、开发到维护运营所需兼任的多项职责。整份资源为单个PDF文件大小仅约15KB内容精炼便携、便于随时查阅目前已有89人浏览学习适合刚接触Web开发、希望快速厘清学习路线与技能地图的初学者。1. “Web基础知识和技术指导”到底该怎么读把参考 PDF 变成施工图这份参考 PDF几乎每个从业者都存过。可现实是真正让你留在行业的从来不是“读完”而是能复现、能排查、能交付。我给新人的建议是把这个标题当成一张施工图而不是百科词条——把 Web 拆成“一个 URL 怎么变成页面”“一个本地工程怎么跑起来”“一个真实服务怎么上线”三条线再补上安全与排查才叫有技术指导价值。这篇文章就按这条线展开从前端三件套到后端接口、从浏览器调试到服务器部署最后落到调试技巧和坑点。适合刚入行的 web 前端开发、转岗的后端工程师以及要搭企业级 Web 开发培训的团队。我不背定义只看现象、抓包、改配置、验证结果。与其花时间找“后悔药”不如用这份基础清单亲手把 Web 请求拆一遍。2. 从 URL 到页面用 curl、DNS 与端口拆开网络黑匣子很多 Web 项目上午还能访问下午就“玄学”了。所谓玄学大概率卡在网络层域名解析走错了、端口被占、缓存没生效。下面用三个可复现动作把它讲透后面所有层的排查都能踩在同一条路径上。2.1 用 curl -v 看完一次 HTTP 请求先不看浏览器直接在命令行里发一次请求。这是观察网络基础最快的方式任何机器上只要有 curl 就能做。curl -v --max-time 10 http://example.com-v是 verbose把 TCP 连接、请求头、响应头全部打印出来--max-time 10是兜底避免 DNS 卡死时脚本一直挂在那里。一般输出里能看到这几段关键信息* Connected to example.com (93.184.216.34) port 80 GET / HTTP/1.1 Host: example.com User-Agent: curl/... HTTP/1.1 200 OK Content-Type: text/html第一行证明 TCP 已连上DNS 成功解析出 IP开头的是你发给服务器的请求头开头的是服务器返回的响应头。这正好对应一次 HTTP 请求的四件事连接要通、路径要对、请求头要全、响应头要懂。很多 Web 前端开发第一次在浏览器里看到报错就慌其实在 curl 里能看到同样的问题。再看 HTTPS 请求重点看证书协商那一段curl -v https://www.baidu.com -o /dev/null 21 | head -40-o /dev/null表示丢弃响应体只看过程21 | head -40是把大量输出截断到前 40 行。这里你会看到 TLS 握手产生的证书链、加密套件等。如果证书过期、域名不匹配curl 会在这一层直接报错而浏览器只是安静地拦下页面。所以排查“页面打不开”之前先用 curl 确认握手是否正常能省一半时间。最后是带请求体的 POST。后端接口联调时很多参数错误其实是 Content-Type 没对上。curl -i -X POST http://127.0.0.1:3000/api/hello \ -H Content-Type: application/json \ -d {name:web}-i会把响应头也打出来确认服务器返回的 Content-Type 是不是application/json-H加自定请求头-d传原始 body。这里要记住一个原则HTTP 是用请求头声明“我发的是什么、我要什么”用状态码表达“结果怎么样”。你后面写的所有代码本质上都是在伺候这两个字段。2.2 DNS 解析与本机端口Web 项目连接故障的第一检查单如果 curl 显示Could not resolve host说明域名解析失败如果显示Connection refused说明目标机器的端口没有进程在听。先跑下面三条命令定位nslookup www.baidu.com cat /etc/hosts ss -lntpnslookup查的是域名当前解析到哪个 IPcat /etc/hosts看本机有没有写死 IP 映射。hosts 文件的优先级高于 DNS 解析很多测试环境的“灵异问题”就是 hosts 里残留了旧 IP。ss -lntp列出本机正在监听的 TCP 端口和对应进程适合排查端口占用。Windows 上对应的两条命令是ipconfig /flushdns netstat -ano | findstr :8080ipconfig /flushdns清空系统 DNS 缓存netstat -ano里的最后一列是 PID拿到后用任务管理器按 PID 找进程即可。这里有一个职场新人容易踩的坑改了域名解析记录本地怎么访问都是旧服务器。原因往往是浏览器缓存、系统缓存、路由器缓存三层叠加。最直接的办法是换一台干净网络的机器验证而不是反复刷新。还有一个经典场景IDEA 2024 创建 Web 项目时内置容器默认监听 8080。你前一个项目没关干净第二个项目启动就报Address already in use。先执行lsof -i :8080看谁占着端口再决定是杀进程还是换 8081。端口不是越多越好越清晰越好。2.3 HTTP 无状态但 Header 驱动登录态到底存哪里HTTP 协议本身不记人。同一个用户连续发两个请求服务器没有机制知道它们来自同一浏览器这就叫无状态。真正把用户串起来的是 Cookie。用 curl 可以完整演一遍登录态的产生和回放# 第一次请求把服务端下发的 Set-Cookie 保存到文件 curl -v -c cookies.txt http://127.0.0.1:3000/api/login # 第二次请求把保存的 Cookie 原样带回 curl -v -b cookies.txt http://127.0.0.1:3000/api/profile-c把响应头里的 Cookie 写入文件-b把文件里的 Cookie 作为请求头发出去。服务端的登录接口一旦验证通过就会在响应头里放Set-Cookie: sessionxxxx浏览器下次请求自动带上Cookie: sessionxxxx服务器靠这个识别身份。这里要分清楚浏览器侧的三种存储存储方式是否随请求自动发送典型用途Cookie是登录态、会话标识localStorage否用户偏好、长期缓存sessionStorage否单标签临时数据很多新手把 token 放 localStorage然后接口每次都要手动拼。能不能用能但刷新页面后你需要自己写初始化逻辑去取。Cookie 的好处是自动携带代价是要处理跨域、SameSite、过期时间等属性。理解这两行 curl再去看后端框架里的 Session、JWT你会瞬间明白它们只是换了一种存放和校验身份的方式底层的坑还是 HTTP Header 那一套。3. 搭建前端工程手写三件套再用 Vite 起一个 Vue 3 Web 项目我建议前端基础必须从“不依赖框架”开始。跳过这一步直接学框架碰到样式不生效、接口跨域、路由 404你根本不知道是框架的问题还是浏览器本身的问题。下面把两条路径都走一遍先用手写三件套理解渲染再用 Vue 3 工程化进入真实业务最后把 Java Web、Go Web 的对照关系讲清楚。3.1 先手写 HTML/CSS/JS理解浏览器从文本到页面的过程新建一个index.html复制下面这段最小页面!DOCTYPE html html langzh-CN head meta charsetUTF-8 title最小 Web 页面/title style body { font-family: system-ui; margin: 40px; } p { color: #333; } /style /head body p idmsg加载中.../p script fetch(http://localhost:3000/api/hello) .then(r r.json()) .then(d { document.getElementById(msg).textContent d.message }) .catch(e { document.getElementById(msg).textContent 接口失败 e.message }) /script /body /html这段代码做了三件事HTML 定义结构CSS 定义外观JavaScript 用fetch请求接口并把结果写进页面。注意script放在 body 末尾因为浏览器遇到script会暂停解析 HTML先去下载和执行脚本。如果脚本放在 head 里页面会出现白屏这是新手最容易忽略的渲染阻塞点。实践里常用script defer让脚本延后执行既不影响 DOM 解析又能保证元素已经存在。把这文件直接拖进浏览器你会发现它没有样式、甚至接口报错。原因很简单浏览器打开本地文件时协议是file://很多功能和 CORS 策略对这种方式不友好。正确做法是起一个本地静态服务下一步的 Vite 会解决这个问题。如果你想把这个页面打印成 PDF按 CtrlP 时打印预览也要走一遍完整渲染如果预览空白优先怀疑是不是有浏览器插件屏蔽了打印弹窗而不是页面代码本身。3.2 Vite 与 Vue.js Web API用两条命令得到企业级前端骨架手写页面理解原理后就该进入工程化了。现在的 Web 项目很少有纯三件套Vue、React 这类框架配合 Vite 已经是企业级 Web 开发的主流底座。用 Vite 起一个 Vue 3 项目npm create vitelatest my-web -- --template vue cd my-web npm install npm run dev第一条命令创建名为my-web的 Vue 模板工程npm install安装依赖npm run dev启动开发服务器默认在http://localhost:5173。生成的结构里src/main.js是入口src/App.vue是根组件src/components放可复用组件。真实业务到后面还会拆出src/api统一管接口、src/router管路由、src/store管状态。脚手架可以生成目录但排查能力必须自己练。接下来把刚才的 fetch 逻辑放进一个组件里完成一次 Vue.js Web API 对接script setup import { ref, onMounted } from vue const msg ref(加载中...) onMounted(async () { try { const res await fetch(http://localhost:3000/api/hello) msg.value (await res.json()).message } catch (e) { msg.value 接口失败 e.message } }) /script template p{{ msg }}/p /templatemsg是响应式变量模板里用双花括号绑定onMounted是组件挂载完成后触发。这段代码和 3.1 的 fetch 本质没有区别只是把 DOM 操作交给 Vue 完成。如果你在浏览器里看到接口失败去看 Network 面板大概率是 CORS 或端口没通下一章会专门讲。3.3 换语言不换思路Java Web 与 Go Web 的相同骨架前端会了后端不要急着选语言。浏览器和服务器之间只认 HTTPJava、Go、Node 写出来的接口对前端来说没有任何区别。以 IDEA 2024 创建 Web 项目为例Spring Boot 里只需一个类就能完成上面接口的功能RestController public class HelloController { GetMapping(/api/hello) public MapString, String hello() { return Map.of(message, 你好Web 基础); } }Go Web 编程里同样简练func main() { http.HandleFunc(/api/hello, func(w http.ResponseWriter, r *http.Request) { w.Header().Set(Content-Type, application/json; charsetutf-8) fmt.Fprintln(w, {message:你好Web 基础}) }) log.Fatal(http.ListenAndServe(:8080, nil)) }看到没有监听端口、读请求路径、设置响应头、写回 body四种语言四个步骤。Java 用注解Go 用函数Node 用回调但底层全是 HTTP 协议。基础一旦立住你在这些技术栈之间切换只是换语法不换思路。这也是我把这份“技术指导”定位成通用地基而不是某一种语言手册的原因。4. 把接口和页面一起跑通Node 起接口Nginx 做静态托管前端开发时跑在 5173接口在 3000这是“开发模式”。线上不能这么裸奔要把静态页面放到标准 Web 服务器里接口也要能扛住进程退出。这一章的目标是走完从npm run build到 Nginx 静态托管、再到进程守护的完整路径。4.1 Node 内置模块起一个零依赖接口不看 Express用 Node 原生http模块就能把接口跑起来。代码越少越容易看清 Web 原理const http require(http) const server http.createServer((req, res) { // 开发阶段放开跨域生产环境必须收紧成自己的域名 res.setHeader(Access-Control-Allow-Origin, *) res.setHeader(Access-Control-Allow-Methods, GET,POST,OPTIONS) res.setHeader(Access-Control-Allow-Headers, Content-Type) if (req.method OPTIONS) { res.writeHead(204) res.end() return } if (req.url /api/hello) { res.writeHead(200, { Content-Type: application/json; charsetutf-8 }) res.end(JSON.stringify({ message: 你好Web 基础 })) return } res.writeHead(404, { Content-Type: text/plain; charsetutf-8 }) res.end(not found) }) server.listen(3000, () { console.log(接口已启动http://localhost:3000) })保存为server.js执行node server.js另开一个终端验证curl -i http://localhost:3000/api/hello你会看到状态码 200、Content-Type: application/json; charsetutf-8和响应 body。代码里的Access-Control-Allow-Origin就是 CORS 的核心允许哪个源访问接口。本地开发图省事用*但生产环境一定写死成你的域名否则任何网页都能向你的接口发请求这是最低门槛的 web 安全事故。OPTIONS分支处理的是浏览器跨域预检前端发application/json这类非简单请求时浏览器会先问服务器“你允不允许”服务器必须回答 204。4.2 Nginx 静态托管与 web 服务器安全最小可上线配置前端执行npm run build后产物在dist/目录。把dist/里的文件放到服务器/var/www/my-web下再用 Nginx 托管。下面是一个能用的最小配置server { listen 80; server_name example.com; root /var/www/my-web; index index.html; gzip on; gzip_types text/plain text/css application/javascript application/json; location / { try_files $uri $uri/ /index.html; } location ~* \.(js|css|png|jpg|jpg|jpeg|gif|svg|woff2)$ { expires 7d; add_header Cache-Control public, no-transform; } }root指定静态文件根目录index index.html表示访问根路径时默认返回index.htmltry_files $uri $uri/ /index.html这句最重要当 URL 路径不存在时把请求回退到前端入口页面这样 Vue Router 的 history 模式刷新才不会 404。gzip相关指令把文本类资源压缩后再交给浏览器能明显减小传输体积。第二个 location 对图片、字体这类体积大又不太变的资源设置七天的浏览器缓存让二次打开更快。改完配置先验证再重载nginx -t systemctl reload nginxnginx -t只检查语法不实际生效systemctl reload会平滑重载配置不会中断现有连接。这两个命令一个用于防翻车一个用于发布。安全加固不要等上线后再做。在 server 块里加上这几行成本极低但能挡掉一批自动化扫描server_tokens off; autoindex off; add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always;server_tokens off隐藏 Nginx 版本号减少被针对性攻击的暴露面autoindex off禁止目录列表防止别人看到你的文件结构X-Content-Type-Options让浏览器不猜测文件类型降低脚本注入风险X-Frame-Options禁止页面被嵌进 iframe。这些都属于基础的 web 服务器安全配置加上之后再用漏洞扫描工具扫一遍告警会少一大截。HTTPS 证书的申请与续期常见做法是用 ACME 自动签发客户端它会自动修改 Nginx 配置并建立定时续期任务。证书没有任何“装完就结束”的说法你要盯的是续期任务有没有跑成功。4.3 进程守护与发布顺序别让接口在终端一关就消失开发时node server.js跑在前台CtrlC 就没了这在生产环境是不可接受的。用 systemd 把接口守护起来[Unit] Descriptionmy-web-api Afternetwork.target [Service] ExecStart/usr/bin/node /var/www/my-web/server.js Restartalways RestartSec3 [Install] WantedBymulti-user.targetRestartalways表示进程意外退出时自动拉起RestartSec3是重启前等三秒防止机器刚起来时环境还没就绪导致反复闪退。写完保存为/etc/systemd/system/my-web-api.service执行systemctl daemon-reload systemctl enable --now my-web-apidaemon-reload让 systemd 读取新配置enable --now设置开机自启并立即启动。发布顺序我的习惯是先npm run build生成新静态文件再替换 Nginx 目录最后 reload Nginx。如果接口逻辑也变了先重启 systemd 服务再 reload Nginx。顺序别反否则用户会先看到新页面打到旧接口上的中间态。防火墙层面对外只放开 80 和 4433000 端口只允许本机访问。这是部署一个新 Web 项目时最容易在最后一步漏掉的安全短板。4.4 开发模式的跨域问题先理解再绕过前端 5173、接口 3000两个端口天然跨域。我在本地调试时纠结过要不要直接改 Nginx 把端口收拢。后来想通了对于初学者就在双端口下把 CORS 配置跑通这是理解“同源策略”最好的现场。生产环境里让 Nginx 把/api开头的请求转发到 Node 端口的做法也很常见原理仍是“改路径、带 Host、放行响应头”等你把 CORS 这节弄懂那套配置就是看一眼就会的事。5. Web 基础避坑指南五个现场最容易翻车的排查清单下面五条都来自真实线上问题按现象、原因、解决三段写。对号入座最快也最适合把它贴到团队 Wiki 里当 Web 项目排查手册。5.1 端口被占用导致服务起不来现象npm run dev或node server.js启动后立刻报EADDRINUSE甚至页面一直转圈。报错里会带端口号最常见的是 3000、8080、5173。原因上一次运行的进程没退出或者有另一个程序抢占了端口。IDEA 2024 创建 Web 项目时前一个 Tomcat 没关干净下一个项目就会踩这个。解决先看端口被谁占用再决定杀进程还是换端口。# macOS / Linux lsof -i :3000 # Windows netstat -ano | findstr :3000拿到 PID 后执行kill -9 PID。如果这个端口是团队的公共约定不要为了省事随手换到别的端口把默认端口保留下来避免换到别的服务的端口上引发更大的事故。5.2 前端路由刷新就 404现象单页应用里点击跳转一切正常但按 F5 刷新后直接 404地址栏路径明明是对的。尤其是配了 Vue Router history 模式的项目几乎必踩。原因刷新时浏览器用真实路径请求服务器服务器发现没有这个文件就回 404。前端路由是给页面在内存里用的服务器不知道document。解决在 Nginx 里给 SPA 加一个回退让它重新加载 index.html。location / { try_files $uri $uri/ /index.html; }这句的含义是先找真实文件找不到就尝试目录再找不到就回退到/index.html由前端路由重新接管路径。加了之后刷新 404 基本绝迹。5.3 中文乱码和 favicon 一直请求失败现象页面中文变锟斤拷浏览器 Console 里favicon.ico一个 404日志里全是噪音。原因HTML 没有声明编码或后端响应头里的 Content-Type 没有带 charset。favicon 是浏览器默认行为项目没放图标文件就会反复请求。解决前端加meta charsetUTF-8后端在响应头里写明白res.writeHead(200, { Content-Type: text/html; charsetutf-8 })favicon 的解决不是删代码而是放一个favicon.ico到静态目录或用link relicon hrefdata:,告诉浏览器“我们没有图标别再造请求了”。出道最低成本的一个坑。5.4 接口请求被 CORS 拦下现象前端报blocked by CORS policy请求在 Network 面板里是红色但 curl 直接访问完全正常。原因你用了浏览器而浏览器在同源策略下发现了“前端 5173、接口 3000”不是同一个源。curl 没有源的概念所以它不会拦。解决在后端响应头里声明允许的来源不要在生产环境用*加凭证。res.setHeader(Access-Control-Allow-Origin, http://localhost:5173) res.setHeader(Access-Control-Allow-Credentials, true)如果要带 CookieAccess-Control-Allow-Origin 不能是*必须是具体源同时要打开 Allow-Credentials。开发环境你也可以让调试服务器把/api开头的请求统一转发到接口端口但这属于“绕过”理解 CORS 本身才是做 web 安全的前提。5.5 HTTPS 页面里混入 HTTP 资源现象页面能打开但图片不显示、接口请求被浏览器自动阻止Console 提示Mixed Content。原因你申请了 HTTPS 证书页面是https://但页面里引用的图片、脚本、接口地址还是写死的http://。浏览器为了防降级攻击直接不加载混合资源。解决把资源地址改成相对路径或协议自适应写法//cdn.example.com/js/app.js让浏览器用当前协议自动拼。更彻底的办法是在 Nginx 里加一个响应头add_header Content-Security-Policy upgrade-insecure-requests always;这行配置让浏览器把所有 HTTP 请求自动升级成 HTTPS。注意它只对页面内发起的请求生效如果 Nginx 后面的接口本身只监听 HTTP你还需要保证服务本身支持 HTTPS 访问。混合内容检查基本是 HTTPS 改造上线后的第一道鬼门关用这招能让你少不少发布会翻车的场面。6. 一个验证技巧60 秒用 Network 面板定位前端问题这一章分享一个我每天都会用的验证方法。遇到“页面好像不对”先别急着看代码打开浏览器开发者工具切到 Network 面板清空日志再手动触发一次出问题的操作。按下面四列依次读第一列是状态码。2xx 就算运输成功3xx 看它重定向到哪里4xx 是客户端问题5xx 基本是后端或网络链路故障。一个常见情形接口返回 304表示浏览器用了缓存如果你刚改了代码却看到 304强制刷新一次再判断。第二列是响应头里的 Content-Type。返回值是text/html前端却按 JSON 解析报错会非常隐蔽。先确认服务器发的是不是application/json再去纠结为什么data是空的。很多所谓的乱码和解析失败都是这一项没对齐。第三列是瀑布图里的等待时间。浏览器发起请求后大部分时间耗在 DNS、等待响应头和下载 body 三件事里。如果 TTFB 特别长问题基本在后端如果 TTFB 很短但下载时间很长通常是接口返回了大体积响应体。第四列是 Initiator它告诉你这次请求是哪个脚本发起的。找前端代码里的具体位置比在 Console 里瞎猜要快得多。我的习惯是每开发一个新功能顺手把功能涉及的请求看一遍状态和类型五分钟后你就对这套 Web 基础是否真的通了心里有数。这个习惯帮我挡掉过很多次评审现场页面打不开的翻车。希望帮到你。本文还有配套的精品资源点击获取