requestmapping path和value为什么不用path_客户端基本不用的算法系列：图论的开端七桥问题...

最新推荐文章于 2024-05-12 08:02:21 发布
最新推荐文章于 2024-05-12 08:02:21 发布
阅读量247 收藏
点赞数
文章标签： requestmapping path和value为什么不用path
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_39977136/article/details/111614079
版权

博客：https://desgard.com

GitHub：https://github.com/desgard

微博：@冬瓜争做全站瓜

冬瓜一直在想着写一个系列来罗列一些在客户端开发中，根本无法用到的算法。但是在计算机科学中又是能独立出来的学科。这之中图论就是一大块。

其实，一切的写作来源都是因为有一天冬瓜在自己的群里讨论了二分图问题，结果发现很多老哥或是一脸懵逼或是喊个 666 防止冷场。虽然在客户端(笔者是 iOS )开发中，这些东西并不常用，深追是根本不用，但是为什么互联网行业能侵入到各行各业的低层和上层，肯定有他自身的原因。当然，计算机科学自身也是一个交叉学科，离不开几何数学、高等数学、数论、图论、博弈论、组合数学、运筹学等等的理论基础。

话题跑偏了，我们继续来说图论。

话题印子

在日常开发中，我们很少接触图论，因为图论多半都是用来解决 N 的子节点的关系问题。但是图论又无处不在。我们通常讲网络作为互联网的代称，在宏观上讲，一个网络其实是组织事物之间的结构。这里我举几个例子：

  • 配电系统

    配电系统中，我们会将多个电站抽象成一个个大的节点，并且每个节点总有输入和输出的电力资源，只要沾上资源，那么就要有开销问题，那么我们如何规划这个电力系统，才能让流量效率(流)和经济成本(费用)得到最合理的分配？你如果是强电或者是弱电专业的童鞋，那你一定知道著名的基尔霍夫电流定律。(笔者是通信的，hhh，还记得被《电路分析》支配的恐惧吗)

    11fb8d27ff8804ceff87c6fd461b7fc8.png

  • 公司关系

    之前我们遇到了很多 P2P 雷暴的新闻，那么其实就带来一个对于公司是否可靠的探究问题。如果我们利用复杂的网路图来抽象出公司之间的担保关系，并评估一下指定公司的连带责任担保，其实就可以分析下担保网络复杂度就可以了。这个场景是来自知乎的一个回答(https://www.zhihu.com/question/40771687/answer/185127200)，个人觉得很有意思。

    https://mp.weixin.qq.com/s/zs2vWfKxD80dg_py2lNy3A

  • 哥尼斯堡七桥问题

    44e6010784cdde0faf4ec99cc9fe6bae.png

    这是一个图论的超级经典问题，你几乎在所有的算法书中(只要目录有图论的)都能看到。这是一个生活问题，当时的哥尼斯堡(现在俄罗斯的加里宁格勒)有如图所示的 7 个桥，小岛与河的两岸由这些桥连接。本着不走回头路的原则，我们到底有没有办法一次性的将所有桥都走过。我们抽象出来建图就是如下场景：

b958ea3bd57ea5d1cdc6acdd74a15c65.png

分析七桥问题

继续趁热打铁，根据上面的场景，我们建一个图来描述这个问题：

207d46ca90e3a1d4fe5997434e69db07.png

我们讲岛屿和大陆抽象成 A、B、C、D 四个节点(Vertex)，将七桥抽象成链接这些节点的度(Edge)，然后我们整理出 N 年以前在大学课堂中学习到的邻接表(如果忘了自己看一眼就明白了? )！

A B C D

A 0 1 2 2

B 1 0 1 1

C 2 1 0 0

D 2 1 0 0

使用下标 1,2,3,4 来对应 A,B,C,D 四个点，我们来构建二维数组 graph[x][y]， x和 y代表两个节点， graph[x][y]代表这两个点之间的路径有几条。然后我们从图中任意找一个起始点，开始DFS(深度优先遍历)所有路径。

为什么要这么做？因为我们现在不知道问题的答案，那么我们就想开发客户端一样，暴力扫出所有的答案。下面我们来确定一个思路：我们在搜索一条路径的时候，每次访问一个节点a，就去查阅我们创建的邻接表，如果邻接表中记录的路径仍旧存在，那么那个节点就是即将行走的下一个节点。由于我们需要在无路可走的情况下返回上层节点，所以最后回溯一下情况，即路径记录数组还原以及邻接矩阵路径还原即可。

下面我用代码来穷举所有的情况：

import copy

graph = [

[0, 1, 2, 2],

[1, 0, 1, 1],

[2, 1, 0, 0],

[2, 1, 0, 0],

]

hash_v = {

0: 'A',

1: 'B',

2: 'C',

3: 'D',

}

hash_v_res = {v: k for k, v in hash_v.items()}

tot_case = 0

def vetex(v: str) -> int:

return hash_v_res[v]

def show_path(path_record: list, g: list):

global tot_case

tot_case += 1

path = [hash_v[i] for i in path_record]

# print('当前路径:')

print(path)

# print('未走的边')

# for i in range(0, len(g)):

# for j in range(0, i):

# if g[i][j] > 0:

# print(f'{hash_v[i]} <=> {hash_v[j]}')

def dfs(g: list, v: int, result: list):

result.append(v)

have_next_step = False

for node, _ in enumerate(graph):

if g[v][node] > 0:

have_next_step = True

g[v][node] -= 1

g[node][v] -= 1

dfs(g=g, v=node, result=result)

g[v][node] += 1

g[node][v] += 1

if not have_next_step:

show_path(path_record=result, g=g)

result.pop()

dfs(g=copy.deepcopy(graph), v=vetex('A'), result=[])

dfs(g=copy.deepcopy(graph), v=vetex('B'), result=[])

dfs(g=copy.deepcopy(graph), v=vetex('C'), result=[])

dfs(g=copy.deepcopy(graph), v=vetex('D'), result=[])

print(f'一共 {tot_case} 种情况')

上述代码中我们穷举了所有的路径，并且可以打印出其路径结果。最后发现一共 100 种方法，每一种都是走到最后无路可走的情况。

['A', 'B', 'C', 'A', 'C']

['A', 'B', 'C', 'A', 'D', 'A', 'C']

['A', 'B', 'C', 'A', 'D', 'B']

['A', 'B', 'D', 'A', 'C', 'A', 'D']

['A', 'B', 'D', 'A', 'C', 'B']

['A', 'B', 'D', 'A', 'D']

['A', 'C', 'A', 'B', 'C']

['A', 'C', 'A', 'B', 'D', 'A', 'D']

['A', 'C', 'A', 'D', 'A', 'B', 'C']

['A', 'C', 'A', 'D', 'A', 'B', 'D']

['A', 'C', 'A', 'D', 'B', 'A', 'D']

['A', 'C', 'A', 'D', 'B', 'C']

['A', 'C', 'B', 'A', 'C']

['A', 'C', 'B', 'A', 'D', 'A', 'C']

['A', 'C', 'B', 'A', 'D', 'B']

['A', 'C', 'B', 'D', 'A', 'B']

['A', 'C', 'B', 'D', 'A', 'C']

['A', 'C', 'B', 'D', 'A', 'D']

['A', 'D', 'A', 'B', 'C', 'A', 'C']

['A', 'D', 'A', 'B', 'D']

['A', 'D', 'A', 'C', 'A', 'B', 'C']

['A', 'D', 'A', 'C', 'A', 'B', 'D']

['A', 'D', 'A', 'C', 'B', 'A', 'C']

['A', 'D', 'A', 'C', 'B', 'D']

['A', 'D', 'B', 'A', 'C', 'A', 'D']

['A', 'D', 'B', 'A', 'C', 'B']

['A', 'D', 'B', 'A', 'D']

['A', 'D', 'B', 'C', 'A', 'B']

['A', 'D', 'B', 'C', 'A', 'C']

['A', 'D', 'B', 'C', 'A', 'D']

['B', 'A', 'C', 'A', 'D', 'A']

['B', 'A', 'C', 'A', 'D', 'B', 'C']

['B', 'A', 'C', 'B', 'D', 'A', 'C']

['B', 'A', 'C', 'B', 'D', 'A', 'D']

['B', 'A', 'D', 'A', 'C', 'A']

['B', 'A', 'D', 'A', 'C', 'B', 'D']

['B', 'A', 'D', 'B', 'C', 'A', 'C']

['B', 'A', 'D', 'B', 'C', 'A', 'D']

['B', 'C', 'A', 'B', 'D', 'A', 'C']

['B', 'C', 'A', 'B', 'D', 'A', 'D']

['B', 'C', 'A', 'C']

['B', 'C', 'A', 'D', 'A', 'B', 'D']

['B', 'C', 'A', 'D', 'A', 'C']

['B', 'C', 'A', 'D', 'B', 'A', 'C']

['B', 'C', 'A', 'D', 'B', 'A', 'D']

['B', 'D', 'A', 'B', 'C', 'A', 'C']

['B', 'D', 'A', 'B', 'C', 'A', 'D']

['B', 'D', 'A', 'C', 'A', 'B', 'C']

['B', 'D', 'A', 'C', 'A', 'D']

['B', 'D', 'A', 'C', 'B', 'A', 'C']

['B', 'D', 'A', 'C', 'B', 'A', 'D']

['B', 'D', 'A', 'D']

['C', 'A', 'B', 'C', 'A', 'D', 'A']

['C', 'A', 'B', 'C', 'A', 'D', 'B']

['C', 'A', 'B', 'D', 'A', 'C', 'B']

['C', 'A', 'B', 'D', 'A', 'D']

['C', 'A', 'C', 'B', 'A', 'D', 'A']

['C', 'A', 'C', 'B', 'A', 'D', 'B']

['C', 'A', 'C', 'B', 'D', 'A', 'B']

['C', 'A', 'C', 'B', 'D', 'A', 'D']

['C', 'A', 'D', 'A', 'B', 'C', 'A']

['C', 'A', 'D', 'A', 'B', 'D']

['C', 'A', 'D', 'A', 'C', 'B', 'A']

['C', 'A', 'D', 'A', 'C', 'B', 'D']

['C', 'A', 'D', 'B', 'A', 'C', 'B']

['C', 'A', 'D', 'B', 'A', 'D']

['C', 'A', 'D', 'B', 'C', 'A', 'B']

['C', 'A', 'D', 'B', 'C', 'A', 'D']

['C', 'B', 'A', 'C', 'A', 'D', 'A']

['C', 'B', 'A', 'C', 'A', 'D', 'B']

['C', 'B', 'A', 'D', 'A', 'C', 'A']

['C', 'B', 'A', 'D', 'B']

['C', 'B', 'D', 'A', 'B']

['C', 'B', 'D', 'A', 'C', 'A', 'B']

['C', 'B', 'D', 'A', 'C', 'A', 'D']

['C', 'B', 'D', 'A', 'D']

['D', 'A', 'B', 'C', 'A', 'C']

['D', 'A', 'B', 'C', 'A', 'D', 'B']

['D', 'A', 'B', 'D', 'A', 'C', 'A']

['D', 'A', 'B', 'D', 'A', 'C', 'B']

['D', 'A', 'C', 'A', 'B', 'C']

['D', 'A', 'C', 'A', 'B', 'D', 'A']

['D', 'A', 'C', 'A', 'D', 'B', 'A']

['D', 'A', 'C', 'A', 'D', 'B', 'C']

['D', 'A', 'C', 'B', 'A', 'C']

['D', 'A', 'C', 'B', 'A', 'D', 'B']

['D', 'A', 'C', 'B', 'D', 'A', 'B']

['D', 'A', 'C', 'B', 'D', 'A', 'C']

['D', 'A', 'D', 'B', 'A', 'C', 'A']

['D', 'A', 'D', 'B', 'A', 'C', 'B']

['D', 'A', 'D', 'B', 'C', 'A', 'B']

['D', 'A', 'D', 'B', 'C', 'A', 'C']

['D', 'B', 'A', 'C', 'A', 'D', 'A']

['D', 'B', 'A', 'C', 'B']

['D', 'B', 'A', 'D', 'A', 'C', 'A']

['D', 'B', 'A', 'D', 'A', 'C', 'B']

['D', 'B', 'C', 'A', 'B']

['D', 'B', 'C', 'A', 'C']

['D', 'B', 'C', 'A', 'D', 'A', 'B']

['D', 'B', 'C', 'A', 'D', 'A', 'C']

一共 100 种情况

我们查看上面的情况发现了一个问题，因为我们有 7 个桥，所以我们如果想全部都走完的话，最少要途经 8 个点。可是穷举的所有答案当中，最多只有 7 个点，也就是说所有的走投无路的情况都无法完成七个桥全部走完。

18世纪时，当这个问题被提出的时候，大家都尝试去解决这个问题，而没有对不存在答案这个答案来做思考。其中 Leonhard Euler 就是就对这个问题产生了疑问，他并没有像其他人一样去解决问题，而是明其不可解决。

7fb134230db170b8f2c755522c34cb68.png

并且从中，Euler 还对问题做了一些升华的思考，他对这个七桥问题(Euler 称之为一笔画问题)给出了一个充要条件：在连通图中，奇点的数目不是 0 个就是 2 个(连到一点的数目如是奇数条，就称为奇点，如果是偶数条就称为偶点，要想一笔画成，必须中间点均是偶点，也就是有来路必有另一条去路，奇点只可能在两端，因此任何图能一笔画成，奇点要么没有要么在两端)。

Euler 的证明思路其实很简单，我们单独来看一个节点，如果我走到这个节点上，那么它必须有一个边让我进来，有另一条不同的边让我出去，除非我们将这个节点作为起始点和终止点。我们再来想想，其实就是一个很简单的道理。

像这样可以一口气走完的图，为了纪念 Euler 这一伟大的证明方法，在图论中被称为欧拉图，且其中经过的路径被称之为欧拉路径。当奇点为零的时候，起始和终止点相同，则走过的路径我们将其画出来后成为一个环，这种情况下这个闭合的路径集合则称之为欧拉回路。

七桥问题也是图论这么学科的起源，也是我们学习图论的开端~ 我们虽然没有欧拉这些科学家的智商，但是我们有计算机+代码，就可以枚举(暴力)出最终结果。至于方法论，就交给科学家来证明好了。工程师的工作就是解决问题。

七桥问题的总结

  • 图：图是由若干给定的顶点及连接两顶点的边所构成的图形，这种图形通常用来描述某些事物之间的某种特定关系。顶点用于代表事物，连接两顶点的边则用于表示两个事物间具有这种关系。

  • 边(度)：连接图中每个节点的路径。

  • 奇点：那些度(对于有向图来说就是出度+入度)数量是奇数的节点。

  • 偶点：对应度的数量是偶数的节点。

  • 欧拉图：可以完成一笔画的图。

  • 欧拉路径：欧拉图中一笔画时经过的路径。

  • 欧拉回路：欧拉图并且一笔画起点和终点相等(欧拉路径成环)的路经集合。

欧拉回路的解题模板

一下是求欧拉回路的 Fleury算法(你们根本想不到还有这种东西)：

// 求欧拉回路或欧拉路，邻接阵形式，复杂度O(n^2)

// 返回路径长度，path 返回路径(有向图是得到的是反向路径)

// 传入图的大小 n 和邻接阵 mat，不相交邻点边权0

// 可以有自环与重边，分为无向图和有向图

#define MAXN 100

void find_path_u(int n, int mat[][MAXN], int now, int& step, int* path) {

　　int i;

　　for (i = n - 1; i >= 0; i --)

　　　　while (mat[now][i]) {

mat[now][i]--,mat[i][now]--;

　 find_path_u(n, mat, i, step, path);

　　　　}

　　path[step++] = now;

}

void find_path_d(int n,int mat[][MAXN],int now,int& step,int* path) {

　　int i;

　　for (i = n - 1; i >= 0;i --)

　　　　while (mat[now][i]) {

　 mat[now][i]--;

　 find_path_d(n, mat, i, step, path);

　　　　}

　　path[step++] = now;

}

int euclid_path(int n, int mat[][MAXN], int start, int* path) {

　　int ret = 0;

　　find_path_u(n, mat, start, ret, path);

　　// find_path_d(n,mat,start,ret,path);

　　return ret;

}

对应习题

HDU 3018 ，POJ 1041 ，POJ 1386，POJ 2230，POJ 2513，POJ 2337，POJ 1392，HDU 2894

推荐阅读
• Hook 那些骨骼惊奇的 Block • 使用 GPUImage 实现一个简单相机 • 深入理解iOS Crash Log • WWDC 2019 ：优秀的开发习惯
weixin_39977136
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
@requestmapping path value区别_【SpringBoot WBE 系列】WebFlux 之 Path 参数解析与 url 映射...
weixin_42385265的博客
12-19 1219
【SpringBoot WBE 系列】WebFlux 之 Path 参数解析与 url 映射异步、反应式、函数式编程，近来可以说是逐渐主流了；Spring5 通过 Reactor 增加了对反应式编程的支持，而 Spring WebFlux 不同于以往的 web 框架，作为一个非阻塞异步 web 框架，可以充分的利用多核 CPU 硬件资源，提供更强的并发支持；Spring 官方对 WebF...
02_SpringCloud客户端负载均衡Ribbon.md
01-03
SpringCloud的复杂均衡 属于客户端；nginx辅助均衡属于服务器端 ,restTemplate 进行RPC调用.对外使用 rest http方式。DiscoveryClient 可以自己实现一个负载均衡的算法(使用请求总数 % 服务列表个数).算法文件跟新...
@RequestMapping value 和 path
a18864802638的博客
12-16 622
在 Spring MVC 中，`@RequestMapping` 注解有两个与路由匹配有关的属性：`value` 和 `path`。- 当你在 `@RequestMapping` 注解上同时使用 `value` 和 `path` 属性时，`path` 属性会覆盖 `value` 属性的内容。- 此时，该注解会匹配 `/users/{userId}` 路径，其中 `{userId}` 是一个占位符，可以匹配任何字符串。- 此时，该注解会匹配 `/users` 路径。
@RequestMapping path正则规范
最新发布
不积跬步无以至千里
05-12 203
在使用 @RequestMapping 注解时，可以使用正则表达式来匹配请求路径。这在需要处理一类路径模式的情况下非常有用。注解是 Spring MVC 中用于映射 HTTP 请求的注解之一。它可以用于处理各种 HTTP 请求，包括。通过合理地使用正则表达式，可以实现更加灵活和精确的请求路径匹配。等，并且可以指定请求的路径、请求方法、请求参数等信息。下面是一个示例，展示了如何在。
requestmapping path和value为什么不用path_从零开始，学习windows编程--环境准备，不用IDE编写程序！...
weixin_39777019的博客
11-25 236
既然是求甚解，那就要脱离掉IDE，保证每个字符都是经过思考产生出来的，其实我们脱离掉IDE环境，更能够了解到每一步的执行是怎么样的，IDE到底在你选择项目、创建项目的时候为了做了哪些事情，还有一个好处就是，当你想写一个小的测试程序的时候，你就不用打开VC，而直接用文本编辑器编写好，直接在命令行中编译运行就可以看到结果了，节约了不少时间。下面，我们就来看看怎么做才可以脱离IDE工作。1...
spring mvc 常用注解详解
Yang_Yvan的博客
11-06 263
@Controller 在SpringMVC 中，控制器Controller 负责处理由DispatcherServlet 分发的请求，它把用户请求的数据经过业务处理层处理之后封装成一个Model ，然后再把该Model 返回给对应的View 进行展示。在SpringMVC 中提供了一个非常简便的定义Controller 的方法，你无需继承特定的类或实现特定的接口，只需使用@Controller 标记一个类是Controller ，然后使用 @RequestMapping 等一些注解用以定义请求URL 请求
spring boot编程思想 pdf_Spring Boot 2 (十)：Spring Boot 中的响应式编程和 WebFlux 入门
weixin_39547392的博客
11-26 651
Spring 5.0 中发布了重量级组件 Webflux，拉起了响应式编程的规模使用序幕。WebFlux 使用的场景是异步非阻塞的，使用 Webflux 作为系统解决方案，在大多数场景下可以提高系统吞吐量。Spring Boot 2.0 是基于 Spring5 构建而成，因此 Spring Boot 2.X 将自动继承了 Webflux 组件，本篇给大家介绍如何在 Spring Boot 中使用 ...
基于框架的Web开发-RequestMapping通配符和占位符.doc
07-04
5.2 @RequestMapping通配符和占位符 1 @RequestMapping注解 类上指定的URL相对于应用根目录 @RequestMapping注解可以使用在控制器类和控制器类的方法上，一般情况下，类定义处的@ RequestMapping提供初步的请求映射...
springMVC笔记.pdf 初学笔记
12-18
RequestMapping可以使用value属性来指定请求的URI，可以使用method属性来指定请求的方法，可以使用param属性来指定请求的参数。 方法参数 SpringMVC的方法参数可以是基本类型、对象类型、Collection类型等。可以...
利用反射获取requestMapping注解的value
04-29
利用反射获取requestMapping注解的value，springMvc实现路径映射功能的逻辑
使用spring.profiles.active来分区配置的方法示例
08-26
@RequestMapping(value = {"/",""}) public String hellTask() { return "hello task !! myage is " + cusvar; } } ``` 这时，spring.profiles.active 的值将决定使用哪个 Profile 文件中的配置项。 使用@...
requestmapping path和value为什么不用path_为什么java是迄今为止最受欢迎的编程语言？...
weixin_39758032的博客
12-02 119
那里有许多编程语言，但是Java在流行性方面击败了它们。毫无疑问，它在最近的一段时间内如此受欢迎已成为一个原因，更不用说它已经摆脱了近二十年半的竞争。因此，百万美元的问题仍然存在：为什么如此受欢迎？任何程序员都会向您确认Java是迄今为止创建的最好的编程语言。当几乎所有《财富》 500强公司都赞成这一事实时，谁能反对这一事实？Java编程既友好又灵活，因此对于Web应用程序开发人员和程序管理专家而...
requestmapping里面的参数_Spring WebFlux之Path参数解析与url映射
weixin_39925413的博客
12-03 510
【SpringBoot WebFlux 系列】WebFlux 之 Path 参数解析与 url 映射异步、反应式、函数式编程，近来可以说是逐渐主流了；Spring5 通过 Reactor 增加了对反应式编程的支持，而 Spring WebFlux 不同于以往的 web 框架，作为一个非阻塞异步 web 框架，可以充分的利用多核 CPU 硬件资源，提供更强的并发支持；Spring 官方对 WebFl...
@RequestMapping属性详解 - SpringMVC高手进阶
陈哈哈的菜园子
03-30 6408
目录前言RequestMapping接口源码解析RequestMapping属性介绍1、name2、value3、path4、method5、params6、headers7、consumes8、produces 前言 在日常java面试中springMVC已经是必不可少的一环了，昨天与几位朋友交流了一下面试SpringMVC框架时的心得。 我们发现大部分面试者仅了解SpringMVC的执行流程...
@RequestMapping注解&@PathVariable 注解
qq_40277163的博客
05-31 632
一、 @RequestMapping注解 SpringMVC 使用 @RequestMapping 注解为控制器指定可以处理那些URL 请求 1.@requestMapping 可以定义在 类 和 方法 上 package com.ibigsea.springmvc.helloworld; import org.springframework.stereotype.Controller; imp...
Request Mapping细节详解
xiao_yan_的博客
10-02 3756
@RequestMapping RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。 (RequestMapping注解的作用是建立请求URL和处理方法之间的对应关系 ) RequestMapping注解可以作用在方法和类上 作用在类上：第一级的访问目录 作用在方法上：第二级的访问目录 细节：路径可以不编写 / 表示应用的根目录开始 细节：${ pageContext.request.contextPath }也可以
如何在刚启动项目的时候触发controller中requestmapping中的Path?
HoneyIrelia的博客
04-01 568
如何在刚启动项目的时候触发controller中requestmapping中的Path?
RequestMapping的用法（完整）
Mr__Charles的博客
02-13 774
spring @RequestMapping 是 Spring Web 应用程序中最常被用到的注解之一。这个注解会将 HTTP 请求映射到 MVC 和 REST 控制器的处理方法上。  在这篇文章中，你将会看到 @RequestMapping 注解在被用来进行 Spring MVC 控制器方法的映射...
@RequestMapping用法详解
biubiubiubibibi的博客
06-30 2143
@RequestMapping用法详解
@RequestMapping（produces = MediaType.APPLICATION_JSON_UTF8_VALUE）是什么意思
03-22
@RequestMapping（produces = MediaType.APPLICATION_JSON_UTF8_VALUE）是Spring MVC中的注解，用于将HTTP请求映射到特定的处理程序方法。它指定了响应的媒体类型为JSON，并且使用UTF-8编码。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值