博客第一阶段前端、后端开发

其实第一阶段的开发已经过去很久了，在放弃独立的完整开发博客这件事情后我也不太想把自己跌跌撞撞的开发过程写得更具体了（绝不是忘记开发过程了）。而且主要的配置相关问题我都在总结中做出了详细的记录，实在是找不到单独为前端以及后端写一些文字的动力，但总比什么都不写好，我还是翻出来几个月前的代码看看是否有什么值得拿出来淡出说说的。

后端的开发采用的是Django框架，Python这一网站开发框架就开箱即用而言确实强了Springboot几条街。就Django的后台管理，我是没想到就注册个管理员然后我的后台管理需求基本就实现了。安装一个接口文档库，接口的测试也就有了路由，虽然我还是觉得 apifox、postman 这类软件测试更合适一些。总之对于我这种开发小白，我肯定是对于这个框架一顿猛夸啊，尽管比起Django的 MTV 结构我还是觉得MVC 结构更清晰一些。

一、后端——DRF技术

开发的主要技术就采用的是 Django REST framwork, 看了B站的教学视频，这项技术我也只能说很Python， 开发起来基本没什么难度。

这里贴出我的DRF全局配置：

REST_FRAMEWORK = {
    'DEFAULT_SCHEMA_CLASS': 'rest_framework.schemas.coreapi.AutoSchema',
    'DATETIME_FORMAT': '%Y-%m-%d %H:%M:%S',
    'DEFAULT_PARSER_CLASS': [
        'rest_framework.parsers.JSONParser',
        'rest_framework.parsers.FormParser',
        'rest_framework.parsers.MultiPartParser',
    ],
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticatedOrReadOnly',
    ],
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.BasicAuthentication',
        'rest_framework.authentication.TokenAuthentication',
    ]
}

主要的配置内容就是采用了什么接口文档、规定了时间格式、设置默认的请求数据解析器（Parsers）他告诉 DRF 处理请求时默认支持哪几种格式、权限配置（这里设置的是非登录用户的只读权限）以及认证方式（这里设置了账号密码认证以及Token认证）。DRF全局配置中最重要的还是权限以及权限认证的配置。

二、后端——APP 的注册

第一阶段的开发开始想写管理端的函数，后面想想又放弃了，主要是 Django 框架自带的后端太好了（没时间不是懒）。这好像和注册APP没什么关系，但简单来说就是最开始的想法和最后的执行总是会有一些偏差，对于这个项目的APP注册来说也是，从最开始设计的四个APP，到最终版本简化为一个我现在也没有认为哪一种设计是对的，但对于我这个简单的项目来说一个APP确实更好。我最终就设计了一个叫 blogclient 的APP，想法很简单，等以后要写管理端了再注册一个 blogserver 的APP（这个以后估计不会有了）。总之，我对于这个 blogclient 的APP还是很满意的，他直接包含了客户端所需的全部功能。

三、前端——Element 组件

这个没什么好说的，毕竟 CSS 这个画笔我不太会用，有element这一组件可以说是大大减少工作量，但尽管如此我前端还是写了一周然后写成一坨，这也是我现在为什么投入博客框架的怀抱的主要原因。抛开我前端设计的问题不谈，element的设计还是很主流很有使用价值，或许当时应该大胆的把 element 组件甩进AI里或许获得的成果要比我自己折腾好几倍。

四、前端——axios

axios 这个放到前端开发来说都是要单独学习源码的，毕竟是重要的网络请求工具，我只是用一下就了解个原理与用法就好。网站开发因为学习或者兴趣的关系时常有接触，而 axios 的使用肯定是绕不开的，现在总结下来还是单独定义一个 request.ts 然后使用 来得最简洁明快。

这里贴上我的 request.ts:

import axios from 'axios'

// 创建一个axios实例
const service = axios.create({
  baseURL: '/blog/client/',  // nginx 会转发到真实的后端
  timeout: 5000,                      // 请求超时设置
})

// 响应拦截器（处理返回结果）
service.interceptors.response.use(
  response => {
    return response
  },
  error => {
    console.error('请求错误：', error.response || error.message)
    return Promise.reject(error)
  }
)

export default service

基本上这样设定好之后，在TS代码中直接导入调用就现得十分一气呵成。

这里再贴上一个请求样例：

const fetchData = async () => {
  try {
    const response = await request.get('file')
    fileData.value = response.data.map((post: any) => ({
      title: post.title,
      created_at: post.created,
      ...
    }))
    counts.value = fileData.value.length
  } catch (error) {
    console.log('数据获取失败', error)
  }
}

这样的 axios 设定以及数据请求流程也就基本上是我前端数据请求的基本操作了。

五、前端——pinia

pinia 作为VUE中数据持久化以及多组件中数据传递最重要的手段之一开始困扰了很久（但是我忘记主要是哪方面困扰我了）。

现在看来也就是，导入、定义、使用 这么一个步骤。

导入：

// 导入 pinia
import { createPinia } from 'pinia'
import piniaPluginPersistedstate from 'pinia-plugin-persistedstate'

定义：

import { defineStore } from 'pinia'
import { ref } from 'vue'

export const useLinkStore = defineStore('bloglink', () => {
  const linkData = ref<any[]>([])
  return { linkData }
}, {
  persist:true,
})

使用：

import { useLinkStore } from '@/store/bloglink'

const blogLink = useLinkStore()

在我的项目里，我也就是对每个博文的链接进行了持久化处理。

六、前端

对于前端再单独说一点，防止以后忘记了。关于博文链接的获取有一些我自认为还不错的设计在里面，因为我的博文界面存在一个面包屑导航，而进入博文界面不仅仅可以从分类界面也可以从归档界面以及搜索界面，如何让这个面包屑导航再各个情况下都能起作用我还是花费了不少时间的，但是我现在也忘记了具体的设计也不太想再细致的分析之前的代码了。如果以后的我再看到这篇博文觉得有些怀念的话就再去看看代码吧。

七、碎碎念

其它的也没什么好说的了，这些文字也只是一个简单的证明，只是一点自我满足而已。这样子，我独自的开发也才能说画上了一个不圆满的句点。