本文最后更新于 223 天前，其中的信息可能已经有所发展或是发生改变,如有失效可到评论区留言。

Contents

Preface

Some time ago, I was reading about how to solve the Ajax cross-domain problem caused by the browser homology policy restrictions. However, when I was thinking about how to write an article to record the relevant knowledge points, I found that it was difficult to explain it clearly from an angle that is easy for ordinary people to understand, and it was even difficult to give examples. Thinking back, this is normal. It is not easy for ordinary people to directly encounter cross-domain problems when visiting websites, and the articles on cross-domain problems on the Internet are basically written by front-end developers.

So what is the browser same-origin policy? What is Ajax? Why does the same-origin policy lead to the problem of Ajax cross-domain access? Why does the front-end always encounter cross-domain problems? Thinking further, why and when did the front-end and back-end become different? . . . Following this line of thought, I found that the above problems are closely related to Ajax. So in this article, I try to use a non-programmer's perspective (after all, I don't understand code, and I don't have a programmer's perspective~) to sort out the relationship between the concepts of "Ajax", "same-origin policy", and "cross-domain". It's so challenging.

The History of Ajax

Web pages before Ajax became popular

Before Ajax became popular, web pages usually worked in a traditional synchronous request mode, which means that when users interacted with the server, the entire page needed to be reloaded. At that time, web pages basically obtained new data or refreshed content through links or form submissions: when a user clicked a link or submitted a form, the browser would send a request to the server, wait for the server to respond, and then replace the entire page with new content.

This synchronous request method has some obvious disadvantages, such as poor user experience, long loading time, etc. In addition, this method also limits developers from implementing more dynamic and interactive functions in web pages.

At that time, web pages usually used static content and a small amount of JavaScript to achieve simple interactive effects, such as form verification, pop-up warning boxes, etc. The content of the entire page was dynamically generated by the server, and the interaction between users and the server was mainly based on a complete refresh of the page.

Another: Do you remember that many years ago when you were surfing the Internet, you would press the "F5" key to refresh the web page whenever there was a problem? This is because you need to completely refresh the page to see the changes in the web page content.

Most people can ignore the following content, but I think it is necessary to record it.

From a technical perspective, before Ajax became popular, there were mainly the following methods to implement dynamic web page functions:

Full Page Reload

The most traditional method is to reload the entire page every time the page content needs to be updated. Although this method is simple, it is inefficient and does not provide a good user experience. Each interaction requires the entire page to be reloaded, resulting in long loading times and high server pressure.

Frames

Using HTML <frame> and <iframe> Tags can divide a web page into multiple independent parts (frames). Each frame can load and update content independently. Although this method can avoid refreshing the entire page, frame management is complicated and is no longer popular in modern web design.

Embedded Scripts

Use scripts embedded in HTML pages to dynamically update page content. For example, JavaScript can directly modify the content of DOM elements. This method is suitable for some simple dynamic updates, but it cannot perform complex data interaction or communicate with the server.

Form Submission with Hidden Frames

By setting the form's target to a hidden <iframe>, you can submit the form and process the response in the background without refreshing the entire page. This method implements asynchronous communication to a certain extent, but it is more cumbersome to use and not as convenient as AJAX.

Server-Side Techniques

Use CGI (Common Gateway Interface) and other server-side scripts (such as Perl, PHP, ASP) to generate dynamic web page content. Although dynamic content can be generated, the page still needs to be refreshed for each interaction.

JavaScript and Cookies

By manipulating cookies with JavaScript, some data can be stored on the client side to achieve limited dynamic functions. For example, part of the page content can be changed according to the user's choice. However, this method is also very limited and cannot perform complex data interaction.

Server Push and Long Polling

These techniques allow the server to push updated data to the client, but are more complex to implement. For example, long polling is a method that keeps an HTTP request open until the server has data to send, but this method puts pressure on server resources.

What is Ajax?

After talking for so long, what exactly is Ajax?

Ajax (Asynchronous JavaScript and XML) is a technology used to perform asynchronous requests and data interactions in Web applications:""It allows data exchange with the server and update of part of the page content without reloading the entire page. Ajax technology enables web pages to achieve more advanced interactions and dynamic effects by interacting with the server in the background."", this was a dramatic change for traditional web pages that mainly displayed page content in a synchronous manner at the time, and dynamic content required a complete page refresh (of course, it took 7 or 8 years from its emergence to popularity). Its core principle includes using JavaScript to initiate asynchronous requests (usually using the XMLHttpRequest object), interact with the server for data, and process the response results in the background. This method allows the page to interact with the server in the background without refreshing the entire page. At the same time, Ajax supports the use of data in XML or JSON format in requests and responses, making data transmission more flexible and efficient.

Question: What is the relationship between JavaScript and Java?
Answer: Actually, there is no connection. They are just two different languages. If you have to force a connection, it is that there are some similarities in core programming concepts and syntax. However, the main reason is to take advantage of the popularity of Java. Because Java was very popular at that time, so it was called JavaScript (originally called Mocha, then LiveScript, and finally decided to change the name to JavaScript).

The Birth of Ajax

In 1996, Microsoft introduced iframes in Internet Explorer 3, which allowed web pages to communicate data in the background without refreshing the page. In 1999, Microsoft introduced ActiveX objects in Internet Explorer 5. XMLHTTP, which was the predecessor of modern AJAX technology.XMLHTTP The object allows the browser to send and receive XML data behind the scenes.

along with XMLHTTP With the introduction of , other browser vendors (such as Mozilla Firefox and Safari) also began to support similar features, and eventually developed into a standard XMLHttpRequest This laid the foundation for the popularization of AJAX technology.

In February 2005, Jesse James Garrett published an article titled "AJAX: A New Approach to Web Applications", in which he first proposed the concept of AJAX and named it AJAX.

Note: AJAX is not a single technology, but a combination of several technologies:

JavaScript: Used to create asynchronous requests and process response data.
XMLHttpRequest: Used to communicate with the server in the background.
HTML/CSS: used for the structure and style of the page.
XML/JSON: used for data transmission and processing. Although XML is in the name, JSON is more commonly used because it is more lightweight and easier to parse.

Changes brought about by the popularization of Ajax

The emergence of Ajax technology has greatly changed the way Web applications are developed, providing users with a better experience. It has also promoted the emergence of more complex interactions and dynamic effects in front-end development, which can be summarized as follows:

Improved user experience

Instant Updates：Users can dynamically obtain and update data without reloading the entire page. For example, the results can be displayed immediately after the form is submitted without refreshing the page.
Smooth interaction: Through asynchronous requests, user operations and page responses are smoother, reducing the inconvenience caused by waiting time and page reloading.

Single Page Application (SPA)

SPA Development: The concept of single page application (Single Page Application, which is an HTML page) has become popular. After the application is loaded, there is no need to refresh the page. All interactions and data loading are completed through AJAX. Frameworks such as Angular, React and Vue.js have promoted the widespread application of SPA.
Modular loading: Pages can dynamically load modules and components as needed instead of loading all content at once, improving the loading speed and performance of the application.

Separation of front-end and back-end

Separation of Duties：AJAX promotes the separation of front-end and back-end. The front-end is responsible for the user interface and interaction, and the back-end provides data services through API. This separation makes the development process more efficient.
API Driven Development：The popularity of technologies such as RESTful API and GraphQL enables the front-end to communicate with the back-end through standardized interfaces, enhancing the flexibility and maintainability of development.

The complexity and functionality of web applications

Live Update: For example, social media platforms can display new content instantly, and e-commerce websites can dynamically update shopping cart and inventory information.
Interactive Experience: Enhanced interaction between users and applications, such as auto-completion, instant verification, real-time search suggestions and other functions.

Note 1: Did we mention earlier that many years ago, when there was a problem accessing a web page, people would press "F5" to refresh it frantically? Although "F5" is still commonly used now, its essential use is different from before: before AJAX became popular, users frequently used the F5 key to refresh the page, usually to ensure that the page was loaded with the latest data or to re-trigger certain operations. Since all the content of the page needed to be reloaded, this method was inefficient and had a poor user experience; after AJAX became popular, since AJAX allows asynchronous data requests without refreshing the entire page, the user experience was significantly improved: users no longer need to frequently use the F5 key to refresh the page content, because some content can be dynamically updated through AJAX. However, the browser cache mechanism still sometimes requires the use of the F5 key to force a page refresh to ensure that the latest resources (such as CSS, JavaScript files or page content) are loaded.

Note 2: Before Ajax became popular, the front-end and back-end were not separated: the front-end developer would write the HTML and CSS structure, and then hand over these HTML files to the back-end developer; the back-end developer would use server-side technology (CGI and other server-side scripts, such as Perl, PHP, ASP) to query data from the database and fill the data into the page; finally, the back-end would return the filled-in page directly to the browser, which means that the browser received an HTML page with data already filled in. This method is called Server-Side Rendering (SSR).

Front-end, back-end and Ajax

In the previous section, we mentioned that Ajax promotes the separation of front-end and back-end. So, what are the front-end and back-end? Why does Ajax promote the separation of front-end and back-end? This section will explain them one by one.

What is the front end?

The front end is what you see and interact with directly when you use a website or application. In simple terms, the front end is the user interface, including the text, images, buttons, forms, etc. on the web page.

For example, when you open a shopping website, you see a list of products, a search bar, a shopping cart button, etc. These are all part of the front end. The job of a front-end developer is to make these things look beautiful, easy to use, and responsive to your operations, such as clicking buttons and entering text.

In a nutshell: The front end is responsible for display and user interaction: it makes the web page look good, the buttons are clickable, and the forms are fillable.

What is a backend?

The backend is the part behind your website that handles the stuff you can’t see, like data storage and business logic.

Let's continue with the previous example: when you click on a product to add to the shopping cart on a shopping website, the front end will pass your operation to the back end. The back end will process this request, such as saving the product information to your shopping cart record in the database, and then return a confirmation message to the front end.

In a nutshell: The backend is responsible for processing data and logic: it receives requests from the frontend, processes data, such as saving it to a database or retrieving it from a database, and then returns the results to the frontend

What Ajax Actually Does

Let's take the previous example: On a shopping website, when you search for a product, you usually don't see the page refresh. Instead, the search results are displayed without reloading the entire page. This is AJAX at work. The front end sends a search request to the back end through AJAX, the back end processes and returns the search results, and the front end then displays these results dynamically.

To sum up in one sentence: AJAX is a bridge between the front-end and the back-end: it allows the front-end to request or submit data to the back-end without refreshing the entire page, thereby improving the user experience.

The popularity of Ajax has accelerated the process of separation of front-end and back-end

There are many reasons for the separation of front-end and back-end, but one of the most important reasons is that the popularity of Ajax has laid a technical foundation for the separation of front-end and back-end, and has promoted the realization of the separation of front-end and back-end to a great extent, which is manifested in the following aspects.

Asynchronous data loading
Traditional server-side rendering:

In traditional server-side rendering (SSR), every user operation or page refresh requires the server to generate a complete HTML page and send it to the client. This method is inefficient and has a poor user experience.
Introduction of AJAX:

AJAX allows the front end to communicate with the server, load or send data without refreshing the entire page. This asynchronous communication method greatly improves the user experience and allows the web page to respond to user operations more quickly.

Implementation of Single Page Application (SPA)
Single Page Application (SPA):

SPA is an application that only requests resources such as HTML, CSS, JavaScript, etc. when it is first loaded. All subsequent page updates are implemented through AJAX requests. SPA manages views and states through JavaScript frameworks (such as React, Vue, Angular) on the front end.
The role of AJAX:

AJAX plays a key role in SPA. The front end obtains data from the server through AJAX requests and dynamically updates the page without reloading the entire page. This method not only improves the user experience, but also reduces the server load.

Clear interface design
Front-end and back-end interfaces:

The separation of front-end and back-end requires that the front-end and back-end communicate through a clear API interface. The front-end calls the API provided by the back-end through AJAX requests to obtain data and update the view.
AJAX Support:

AJAX allows the front-end to easily call the back-end API, obtain the required data and process the data, ensuring that the communication between the front-end and the back-end is efficient and flexible.

Shift in development paradigm
Parallel development:

The separation of front-end and back-end allows the front-end and back-end teams to develop in parallel, reducing mutual dependence and blocking. Front-end developers can use AJAX to obtain mock data from the Mock server for development without waiting for the back-end API to complete.
Popularity of AJAX:

The popularity of AJAX technology allows the front-end to be developed and debugged independently of the back-end, greatly improving development efficiency.

Performance Optimization
Asynchronous loading:

AJAX can be used to load data on demand, reducing initial page load time and improving performance. Users only load additional data when needed, rather than fetching all the data at once when the page loads.
Data update:

The front end can implement partial page updates through AJAX instead of reloading the entire page every time, which reduces network traffic and improves response speed.

Better user experience
Dynamic Interaction:

AJAX enables web pages to achieve more dynamic and rich interactive effects. For example, form validation can be performed in real time while the user is inputting, without having to display error messages after the form is submitted.
Data refresh:

Through AJAX, web pages can automatically refresh data in the background without the user having to manually refresh the page. This approach is particularly important in real-time applications (such as chat applications, stock quotes, etc.).

Browser Same-Origin Policy Restrictions

The article begins by mentioning that the Ajax cross-domain problem is caused by the browser's same-origin policy. To solve it, we must first clarify what the same-origin policy is and why it is needed.

What is the Same Origin Policy?

The same-origin policy is a rule used by browsers to protect user privacy and security. It stipulates that content on one website cannot access content on another website at will unless the two websites have the same origin. The "same origin" here can be understood as coming from the same place (i.e. the same protocol, domain name and port, important: the three must be exactly the same).

Why do we need the same-origin policy?

The same-origin policy is like setting a security door for each website, so that the content and data of each website can only be controlled and accessed by itself. In this way, even if you open multiple websites at the same time, the information between them will not be leaked or abused, which greatly increases your online security and allows you to use various online services more confidently.
For example:

Prevent malicious operationsWithout the Same Origin Policy, a website you don't trust might use your login status on another website to secretly perform some operations, such as posting on your social media account, purchasing something on your shopping website, or transferring money on your bank website. This is as scary as someone using your credit card to make purchases without your knowledge.
Preventing Data Breaches: The same-origin policy also ensures that the content of the form you fill out on one website cannot be seen by other websites. It's like you are talking about private matters in a closed room, and people in other rooms cannot hear you, so your privacy is protected.

Cross-domain issues caused by the same-origin policy

The same-origin policy restricts browsers from directly interacting with each other on different domain names, ports or protocols. This restriction leads to cross-domain issues. The following are some specific examples to illustrate why the same-origin policy can cause cross-domain issues:

1. Example: Accessing data from one domain name to another domain name

Suppose we have two websites:

Website A: https://www.tangwudi.com
Website B: https://blog.tangwudi.com

In the front-end JavaScript of website A, if you try to directly access the data of website B through an AJAX request, for example:

fetch('http://blog.tangwudi.com/data') .then(response => response.json()) .then(data => console.log(data)) .catch(error => console.error ('Error:', error));

The browser will block this request because they are from different domains ( www.tangwudi.com andblog.tangwudi.com), which violates the same-origin policy. This is because the same-origin policy requires that the domain name must be exactly the same, including the protocol (https://), domain name (example.com), and port (if any).

2. Example: Use different ports to access data of the same domain name

Suppose we have the same website, but on a different port:

Website A: https://www.tangwudi.com
Website B: https://www.tangwudi.com:8080

If website A tries to access data from website B via an AJAX request on the front end, for example:

fetch('https://www.tangwudi.com:8080/data') .then(response => response.json()) .then(data => console.log(data)) .catch(error => console .error('Error:', error));

Similarly, the browser will block this request because although their domain name and protocol are the same, the ports are different. Similarly, "http://www.tangwudi.com" and "https://www.tangwudi.com:8080" also violate the same-origin policy.

3. Example: Using different protocols to access data on the same domain name

Suppose we have the same website, but on a different protocol:

Website A: https://www.tangwudi.com
Website B: http://www.tangwudi.com

If website A tries to access data from website B via an AJAX request on the front end, for example:

fetch('http://www.tangwudi.com/data') .then(response => response.json()) .then(data => console.log(data)) .catch(error => console.error ('Error:', error));

Similarly, the browser will block this request because although their domain names are the same, the protocols are different (https and http), and the same-origin policy also prohibits such cross-protocol requests.

Ajax cross-domain access solution

Why is there a cross-domain demand?

This is because of the actual development needs. In many cases, it is necessary to request resources that are not in the same domain as the current web page. The specific reasons may include:

Microservice architecture: Modern Web applications often use microservice architecture, where different services are deployed on different domain names or subdomains. Front-end applications need to access these services across domains.

CDN resource loading: To speed up resource loading, static resources (such as images, scripts, style sheets) are usually hosted on a content delivery network (CDN), and the domain name of these resources is different from the main site.

Third-party API calls: Front-end applications may need to call API services provided by third parties. These API servers are usually located under different domain names.

Separate development environment: The development and test environment may have different domain names from the production environment. During the development process, the front-end application needs to access the back-end service across domains.

Ajax cross-domain access method

The following are some common methods to solve Ajax cross-domain access.

1. JSONP (JSON with Padding)

JSONP is an early method to solve the cross-domain problem by dynamically creating<script>Tag to request cross-domain resources, because<script>Tags are not restricted by the same-origin policy.

Example:
Suppose you have a cross-domain API http://tangwudi.com/dataYou can use JSONP like this:

<script>
Function handleResponse(data) {
    console.log(data);
}

var script = document.createElement('script');
script.src = 'http://tangwudi.com/data?callback=handleResponse';
document.body.appendChild(script);
</script>

In this case, the server needs to wrap the response in a callback function, for example:

handleResponse({ "message": "Hello, World!" });

Note: JSONP is suitable for simple cross-domain situations that only support GET requests

CORS is a mechanism supported by modern browsers that allows the server to tell the browser to allow cross-origin requests by setting HTTP headers.

Example:
On the server side (assuming Node.js and Express):

const express = require('express');
const app = express();

app.use((req, res, next) => {
    res.header('Access-Control-Allow-Origin', '*'); // Allow all domain names to access
    res.header('Access-Control-Allow-Methods', 'GET,POST');
    res.header('Access-Control-Allow-Headers', 'Content-Type');
    next();
});

app.get('/data', (req, res) => {
    res.json({ message: "Hello, World!" });
});

app.listen(3000, () => {
    console.log('Server running on port 3000');
});

On the client side (browser side), you can directly use AJAX request:

fetch('http://localhost:3000/data')
    .then(response => response.json())
    .then(data => console.log(data));

Note: CORS is a method recommended by modern browsers. In the scenario where the front-end accesses the back-end across domains, it needs to be set up on the back-end server.

3. Reverse Proxy Server

By setting up a proxy on the same-origin server, the request is forwarded to the target server to avoid direct cross-domain requests.

Example:
Assume that your front-end server is http://localhost:3000 and the API server is http://tangwudi.com.

Set up a proxy on the front-end server to accesshttp://localhost:3000/apiRequest, reversed tohttp://tangwudi.comOn (example using Node.js and http-proxy-middleware):

const { createProxyMiddleware } = require('http-proxy-middleware');
const express = require('express');
const app = express();

app.use('/api', createProxyMiddleware({ target: 'http://tangwudi.com', changeOrigin: true }));

app.listen(3000, () => {
    console.log('Frontend server running on port 3000');
});

Then do the following on the client:

fetch('http://localhost:3000/api/data') .then(response => response.json()) .then(data => console.log(data));

Note: The above three methods are mainly solutions to the AJax cross-domain problem. In fact, general cross-domain access can also use the src attribute in several tags in HTML to share cross-domain resources. For example:
<script> The tag can be used to load JavaScript files across domains

<script src="https://example.com/some-script.js"></script>

<img> Tags can be used to load image resources across domains

<img src="https://example.com/image.png" alt="Example Image">

<link> The tag can be used to load CSS style sheets across domains

<link rel="stylesheet" href="https://example.com/styles.css">

<iframe>The tag can be used to embed cross-domain web content

<iframe src="https://example.com"></iframe>

and The tag can be used to load audio and video files across domains.

<audio Controls>
  <source src="https://example.com/audio.mp3" type="audio/mpeg">
</audio>

<video Controls>
  <source src="https://example.com/video.mp4" type="video/mp4">
</video>

Is cross-domain relevant to ordinary people?

Cross-domain is a concept that is difficult for most people to understand, because it is a problem that needs to be solved during application development. When the application is developed and tested and opened to the public, a unified UI with cross-domain problems has been solved. All content and functions on this UI must be in the same domain under normal circumstances (of course, a few special cases are not excluded, but in that case, even if an error is reported, it is reported in the browser's developer console. Most people will not take the initiative to open the developer tools, so they still cannot see it).

However, although ordinary users generally do not see cross-domain issues directly, in some cases, users may encounter some errors or abnormal behaviors caused by cross-domain issues. For example, the following possible situations are caused by cross-domain issues:

Data failed to load

Performance: Some data on the page cannot be displayed, such as product lists, comments, news content, etc. are blank or not updated.
reason: The AJAX request was blocked due to a cross-domain issue, causing the data to fail to load from the server.

Abnormal function

Performance：Some functions cannot be used normally, such as searching, submitting forms, liking, etc.
reason：These operations usually require communication with the server. Cross-domain issues may cause the request to be blocked, making the function unable to be executed.

Console error

Performance: When users open the browser's developer tools (although ordinary users don't often do this), they may see cross-domain related error messages, such as Access-Control-Allow-Origin mistake.
reason: The cross-origin request is blocked by the browser's same-origin policy, and detailed error information will be displayed in the console.

Failed to load static resources

Performance：The page style is disordered, pictures cannot be displayed, JavaScript functions are invalid, etc.
reason: If static resources (such as CSS, images, and scripts) fail to load correctly due to cross-domain issues, the page may not render properly.

The current state of Ajax

This article uses Ajax technology as the core to associate other concepts. In reality, although Ajax is still an important technology, its usage and role have changed with the advancement of front-end development.

The core role of AJAX remains unchanged

The core concept of AJAX - asynchronous data request and partial page update - is still the cornerstone of modern front-end development. Whether through native XMLHttpRequest or through the Fetch API, asynchronous requests are the main way for the front end to interact with the server.

The rise of modern alternatives and tools

Although AJAX as a technical concept still exists, many modern tools and frameworks provide higher-level abstractions and more convenient ways of using it:

Fetch API: A native API for modern browsers that provides a simpler and more flexible way to make network requests. It is an improvement on XMLHttpRequest.

fetch('https://api.example.com/data') .then(response => response.json()) .then(data => console.log(data)) .catch(error => console.error ('Error:', error));

Front-end frameworks and libraries：React, Vue, Angular and other frameworks and libraries usually integrate data request methods and tools, making it easier to handle asynchronous data requests. For example, the axios library commonly used in React:

import axios from 'axios'; axios.get('https://api.example.com/data') .then(response => console.log(response.data)) .catch(error => console.error( 'Error:', error));

GraphQL: A query language for APIs that allows clients to request the exact data they need, reducing the redundant data problem of traditional RESTful APIs. Apollo Client is a commonly used client library for GraphQL.

The popularity of single-page applications (SPA)

Single-page application (SPA) frameworks, such as React, Vue, and Angular, have greatly changed the way front-end development is done. These frameworks provide a higher level of component-based development and state management, making AJAX calls part of their larger system.

SSR (Server-Side Rendering) and Static Generation

Frameworks such as Next.js (based on React) and Nuxt.js (based on Vue) support server-side rendering (SSR) and static generation (SSG), which pre-fetch data during the build process, thereby reducing the need for AJAX calls on the client side. These frameworks can still make AJAX calls after client-side rendering, but their use and purpose are different from traditional AJAX calls.

Advances in Web Technology

With the development of Web technology, technologies such as Service Workers and WebSockets provide more real-time communication and offline functions. These technologies expand the capabilities of traditional AJAX, allowing front-end developers to build richer and more dynamic applications.

Combined with modern development tool chain

Modern development tool chains (such as Webpack, Babel, etc.) and development patterns (such as modular development, micro-frontend architecture, etc.) also affect the use of AJAX. These tool chains and patterns make code organization better and performance optimization more convenient, while also simplifying the complexity of data requests and processing.

Afterword

This article is very difficult to write. I need to keep clearing my thoughts. The information on the Internet is basically from the perspective of programmers. As long as a piece of code is posted, the example is basically explained clearly. However, many basic concepts that are common sense and do not need to be mentioned to them are half-understood words for ordinary people (or non-programmers). The more I read, the more confused I feel. So in order to explain it basically, I need to sort out the concepts one by one. It's tiring. After all, I am not a professional.

In addition, although I have tried my best to control the use of code for examples (because I am worried that non-IT professionals may not understand it), there are some concepts that can be demonstrated with simple code rather than thousands of words. Perhaps my knowledge accumulation is too poor, and I can’t think of a more easy-to-understand and concise explanation. I can only make up for this through continuous learning in the future.

So, what is the point of writing this article? After thinking for a long time, it seems that it is really useless: programmers don’t need to read it, and ordinary people don’t need to read it either.

However, for me, if I want to get involved in the field of code in the future, this article will be a good basic guide to give me a general direction.