关于前后端联调,后端问题需要依赖于复杂页面交互,是怎么接入前端来调试后端问题的呢

一般都是反过来的。因为后端是比较好构造逻辑调试的。反而前端是不容易构造一些数据和环境的。
这点从单测上就能看出来

后端对着 postman 自动脑补画面，这是基本功

我是使用浏览器扩展 https://github.com/g0ngjie/ajax-proxy 重定向前端的接口到本地服务器（服务需要配置一下 cors ），所有在原本的前端页面发起的请求都过来了

自己发 api 测啊，postman 是干啥使的？

话说回来,好多前端连 copy as curl 都不知道

我是后端，如果线上的开发环境不理想，对于特别复杂的页面，涉及好多个接口好几个后端服务的，我都是自己本地启动前端调试

我同事都是在她电脑本地启动前端项目，自己调用页面调试的

A 就是有问题，哪怕是刚接触项目要从界面熟悉接口，也应该找楼主问前端编译好的项目和启动方式，而不是强奸楼主的时间

简单，让运维在开发环境也正常部署前端代码不就完了。

@wangritian #48 三年起步

@lozzow #45 之前都是 打开浏览器请求 址 和 参数 一个一个复制的

@xuanbg #49 没有运维 服务器密码给你 前端后端分开部署自己的

A 比较水，一般是用 postman 之类的 http 客户端工具测试接口有没有问题

我特别想知道,没有相对稳定的开发测试环境的话,你们测试都是怎么工作的

@spritecn #54 有开发环境,但开发环境前后端都是打包部署后的,现在问题是后面想连本地调试

想本地调试喊他自己运行啊，装个 node 又不麻烦

看样子 op 和我司的环境比较像, 测试开发环境在公网, 不能连接本地, 本地能访问测试开发环境.
而且后端还是微服务, 网关, 授权, 注册中心等都在公网(由于公网不能访问本地所以注册上去也没用).
这种问题其实很简单, 这是我的解决办法:
后端只需要本地启动一个 nginx 就行了,
除了需要 debug 的微服务代理到本地, 其他所有的全部走测试,开发环境;
比如测试环境在 test.com, 现在后端觉得有一个微服务 svc-x 有问题, 需要联调,
可以这样配置:
```
server {
listen 7004;
server_name localhost;

# 这里主要是看网关路由的配置是什么, 一般现在前端和后端的路由是有区别的
# /svc-x 的服务全部走到本地, 并且去掉/svc-x path
location /svc-x/ {
proxy_redirect off;
proxy_pass http://localhost:8080/;
proxy_connect_timeout 15s;
proxy_send_timeout 15s;
proxy_read_timeout 15s;
proxy_set_header X-Forwarded-Proto http;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

location / {
proxy_pass http://test.com;
proxy_connect_timeout 15s;
proxy_send_timeout 15s;
proxy_read_timeout 15s;
proxy_set_header X-Forwarded-Proto http;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
```

这样随时使用开发测试环境的前端以及后端鉴权等.

@lozzow #45 你以为后端知道? 我发一个 curl 还在里面一个一个扒入参呢

之前 leader 推广过前端微服务，我写了个 Chrome 扩展插件，用于测试线上环境的，本质上就是通过 Chrome 的插件来修改请求调用的网关地址。

同样的，可以让后端浏览器装个插件，把请求转发到他本地服务，就不需要依赖前端了

以前用的这个 Chrome 插件，https://github.com/yize/xswitch ，一把抓住前端请求，顷刻炼... 转发到本地后端。

不过这个插件现在不维护了，使用油猴脚本、或者 whistle 之类的代理工具也能轻松实现。或者让 ai 给你写个 Chrome 插件来转发。