foreword
Last year, because of the change of work, I have been writing business code, but I have not encountered anything to write. Just yesterday, a bug in the test environment broke out. After investigating for more than an hour, I finally solved the problem, and I made up my mind to do it in the future. Test the production package yourself before giving it to the test package (would rather kill yourself than let the test raise one more bug).
technical pit
When I came to the new company, I showed my ambition and decided to plan the front-end development route. Of course, I would not let vue3+vite choose vue3+vite when I was at the forefront of the trend. So the first project still chose vue3+webpack, don't ask why webpack, ask is require. As we all know, require cannot be used in vite, and most of the frameworks used for rapid development on the market are still in the vue2 stage, and the svg in it still uses various require. I don't have much development time. I still replaced vite with webpack. It hurts, it hurts too much.
scene reproduction
Because the epidemic situation in Nanjing has become more serious recently, the company has started working from home. I am so happy. The cute kitty accompanies me to type codes, and even the efficiency has become much higher. After the two difficult days before and after the back-end joint debugging was completed, I happily packaged it for the test. After half an hour, WeChat rang. Why is this xxx page open and always loading? How much did you set the maximum time for the request? Is there a problem? Open the code decisively and see, 10000ms, which is quite long. Confidently told the test sister: I gave 10S, enough interface response. So I tested the remote intranet and opened the page and told me that the intranet didn't work. I don't know what happened now. I confidently said that I would try it and link the local address to the test environment. Hey, I'm fine, specially Screenshots for testing, you see, is it good. The test sister gave me a scolding. I asked you to open the test address instead of letting you run locally. So I opened the page and found that it was actually loading all the time, because in addition to the development environment, I had cleared the console and I could not see any errors reported. After a long half-hour wait, the deployment is finally completed. It is so troublesome to complain about home office and packing! ! ! Then I went up to see and found that it was wrong, as shown in the figure.
How can it exceed the maximum stack? I looked at my code and fell into contemplation. I reviewed the code on one side. There is no recursion, no infinite loop. Well, the problem is not in the code, for sure! I started to go crazy with Baidu. I saw someone saying that the namespace has the same name. I changed the name again, packaged it, and took half an hour. . . Well, if there is no accident, there is an accident, and the same error is still reported. Focusing back on the code again, printing one by one, and finding that the data printed out is very strange, and the development environment and test environment are different. Data are as follows
It was found that the problem appeared in...status.queryForm. It was clearly initialized with empty data, but a lot of things would be structured. Because the development environment did not report an error, this problem was ignored at the time. I didn't expect the problem to break out after packaging. Since there is a lot of data in it, there must be an assignment operation, but after reading the code, there is no such thing. Where is the problem? After dinner, staring at the code suddenly discovered the mystery!
<el-form :model="queryForm" ref="queryForm" :inline="true" size="small">
复制代码We know that to use ref in vue3, we need to define ref first. It is unfortunate that my ref has the same name as the data deconstructed from toRefs, so it will be initially assigned, and finally the bottom line is out hahaha. Although I don't understand why after packaging... deconstruction will exceed the maximum stack, if anyone sees it, you can comment, but the problem is indeed solved. Packaging, when I was about to send it to the test, I suddenly wondered what to do if there was a problem. It would be a waste of time to wait for half an hour to deploy at a time. Is there any way to test the packaged package locally?
Local test online package
The reason why the server can run the project is because of nginx, so we can test the package with nginx locally, and we can do it: The following is the content of nginx.conf:
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
client_max_body_size 10240m;
server {
listen xxxx;
server_name localhost;
# default_type 'text/html';
#charset utf-8;
proxy_set_header X-Real-IP $remote_addr;
}
server {
listen xxx;
server_name localhost;
location / {
root D:\xxxxx\dist;
index index.html index.htm;
autoindex on;
autoindex_exact_size off;
autoindex_localtime on;
}
location /api {
proxy_pass http://xxxx;
}
}
}
复制代码Because it involves privacy, some IPs are hidden, and you can define them yourself. I happily tested the bag, um, no problem, I can finally give my sister a good bag.
文章创作于2022-02-24
复制代码