如何在项目中更好的动态使用图片？能否把删除数据的接口统一到更新数据的接口中？

本文链接：https://blog.csdn.net/qq_47199913/article/details/138837898

1. 如何在项目中动态使用图片？

通过在后台将图片上传至服务器后，服务器端可以设置针对国旗类图片的上传接口的参数类型来指定上传至哪个目录，例如：

1）图片上传接口地址为：https://xxxx/uploadImg/

2) 上传参数：type:1（国旗）type：2（头像） type:3 （logo）....

3) 通过type类型后端可根据类型来指定对应type图片的文件夹地址，例如：type为1的图片上传至https://xxxx/country/文件夹下 type为2的图片上传至https://xxxx/avatar/文件夹下。。。。

这样一来前端在拿到接口数据时根据item.country字段来判断是哪个国家，图片可以直接以以下形式即可：

`https://xxxx/country/${item.country}.png`

此外，每次渲染图片加上前缀显得代码很冗余，我们可以根据实际情况将前缀放入.env配置中：

//.env.development文件===>开发环境配置文件

//开发环境接口地址
VITE_API_BASE_URL= 'http://xxxxxx:5000'

//开发环境头像前缀
VITE_ASSETS_AVATAR_PATH=http://xxxxxx/avatar/

//开发环境国家前缀
VITE_ASSETS_COUNTRY_PATH=http://xxxxxx/avatar/

//.env.production文件===>生产环境配置文件

//生产环境接口地址
VITE_API_BASE_URL= 'https://xxxxxx:3000'

//生产环境头像前缀
VITE_ASSETS_AVATAR_PATH=https://xxxxxx/avatar/

//生产环境国家前缀
VITE_ASSETS_COUNTRY_PATH=https://xxxxxx/avatar/

以上环境变量配置好之后我们可以在hooks中（也可以在utils工具类中写入，地方不限）写一个独立的函数用来返回图片地址：

//import.meta.env.VITE_ASSETS_COUNTRY_PATH==>用于返回当前环境配置字段的对应信息
export default function useCountry() {
  // 国家头像
  const getCountry = (country: string) => {
    return import.meta.env.VITE_ASSETS_COUNTRY_PATH + country + ".png";
  };
  return {
    getCountry,
  };
}

最终，引入hooks并使用图片：

//javascript模板中
import { useCountry } from "@/hooks/index";
const { getCountry } = useCountry();

//Vue3模板中
<img
 :src="getCountry(item.country)"
 alt=""
 class="xxxxx"
 />

这样图片就成功引入到项目中中了，当然细节的小伙伴为了以防万一图片找不到也可以添加一个图片无法找到的占位图片，例如：

<img :src="getCountry(item.country)" onerror="https://example.com/placeholders.jpg">

2. 能否把删除数据的接口统一到更新数据的接口中？

事情是这样的，公司做的一个前端页面要用到很多国家的国旗，直接将图片上传到服务器很麻烦很费事又很不好维护，于是我就在后台做了一个tab页专门用于对前端图片的维护（增删改查），这样下来既清晰又容易维护，下面是大概页面：

然后问题来了，拿到接口之后我只看到了三个接口：

1）获取/查询列表数据的接口

2）添加数据的接口

3）更新数据的接口

我看到缺少了删除接口和分页接口，于是找领导询问，领导说删除接口就用更新接口就行了，只不过要变一个字段，后端拿到该字段之后会在数据库表中进行物理删除；分页接口就使用前端分页即可，数据量不是很大没必要用后端分页，世界上一共才多少个国家，我们有生之年也不会看到成千上万个国家，听完之后我就挺无语的，觉得领导考虑的挺周到的哈哈哈哈哈哈~

至于删除接口归并到更新接口我还是存在一点质疑的，毕竟一码归一码，就拿大学学习的设计模式的十大原则之一“单一职责原则”来讲也说不通，另一方面它也不遵循RESTful设计原则，我不知道这个地方是不是领导想省事偷个懒（领导看不到，领导看不到，领导看不到），但从另一方面来讲它比较简便省事，减少了API的数量，减少开发和文档编写的工作量，具体哪一点这样做我也不太清楚。

兄弟们，你们觉得呢？评论区发表一下意见探讨探讨~