前端 / 后端 / 部署实践

个人技术分享

把问题弄明白,把过程记下来。这里收录互联网开发中的学习与实践笔记。

技术笔记

01 / 前端基础

一个页面,从清晰的 HTML 开始

先组织内容,再处理布局,最后添加真正需要的交互。

写页面时,先把标题、正文、导航和补充信息分清楚。语义化标签不只是换一种写法,它能让浏览器、搜索工具和辅助技术更准确地理解内容。

  • 用 header 和 nav 表达站点导航,把主要内容放进 main。
  • 标题按内容层级组织,不要仅为了字号选择标题级别。
  • 图片提供贴合内容的替代文本;装饰图片使用空的 alt。
  • 操作用按钮,跳转用链接,并保留清晰可见的键盘焦点。
<main>
    <article>
        <h1>一篇开发笔记</h1>
        <p>先把内容结构表达清楚。</p>
    </article>
</main>

布局完成后,检查长标题、窄窗口和键盘操作。页面能在没有脚本的情况下展示核心内容,通常也是一个值得保留的基础。

延伸阅读:MDN 的语义说明
02 / 后端接口

接口设计,先约定成功与失败

让调用方知道发生了什么,也让问题更容易定位。

接口文档至少要说明请求方法、参数、成功结果和错误结果。前后端对这些边界达成一致,比先写出一个只能处理正常情况的接口更有用。

  • 查询通常使用 GET,创建资源通常使用 POST;不要让查询请求产生写入副作用。
  • 服务端仍须校验参数和访问权限,不能只依赖页面上的输入限制。
  • 用合适的 HTTP 状态码表达结果,并提供稳定、可识别的错误代码。
  • 错误响应不返回密码、访问令牌、数据库语句或内部堆栈。
HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "code": "INVALID_TITLE",
    "message": "标题不能为空"
}

对于可能被重复提交的写入请求,还应根据业务设计幂等机制。日志可以保留请求标识帮助排查,但应避免记录不必要的个人信息和凭据。

延伸阅读:HTTP 响应状态码
03 / 部署记录

静态网站上线前的四项检查

文件传到了服务器,不等于访问链路已经完整。

  1. 域名解析:核对主域名和常用子域名的记录,确认它们指向正确的服务器。没有配置 IPv6 服务时,不要留下错误的 AAAA 记录。
  2. 站点路由:Web 服务器应按域名选择对应目录,未知路径返回正确的 404,不要暴露配置文件和目录列表。
  3. 页面与资源:检查中文编码、图片、站内链接和不同窗口下的排版,并确认备案信息与实际站点一致。
  4. HTTPS 与回退:启用 HTTPS 时,证书应覆盖实际使用的域名,并配置续期;每次更新保留上一版文件,以便必要时回退。

更改服务器配置前先做语法检查。发布后从外部网络重新访问页面,同时确认同一服务器上的其他站点仍然正常。

延伸阅读:Nginx 入门文档