Abstract
This is a standard for hashing and signing of typed structured data as opposed to just bytestrings. It includes a

theoretical framework for correctness of encoding functions,
specification of structured data similar to and compatible with Solidity structs,
safe hashing algorithm for instances of those structures,
safe inclusion of those instances in the set of signable messages,
an extensible mechanism for domain separation,
new RPC call eth_signTypedData, and
an optimized implementation of the hashing algorithm in EVM.
It does not include replay protection.

Use Case:

Key signatures
IDEX requires the aggregation of orders on a centralized server, how do we ensure that orders are not altered by the exchange? The core lies in the fact that each of our transactions is signed with the user's own private key before it is sent to the centralized server, and then the smart contract will verify the user's signature when it performs settlement. If the centralized server makes any changes to the order data, it will not pass the smart contract's verification.

How to put EIP712 to use
Let's take an auction scenario as an example to see how to put EIP712 to use in a product.

Defining the data structure
First, list the data to be signed by the user in JSON format. For example, as an auction application, the following bid data is required to be signed

{
    amount: 100, 
    token: “0x….”,
    id: 15,
    bidder: {
        userId: 323,
        wallet: “0x….”
    }
}

Then, we can distill two data structures from the above code snippet: Bid, which contains the bid amount determined by the ERC20 token asset and auction id, and Identity, which specifies the user id and user wallet address.
Next, the Bid and Identity are defined as structs, and the following solidity contract code can be written. The full list of data types supported by EIP712, such as address, bytes32, uint256, etc., can be viewed in the EIP712 draft protocol.

Bid: {
    amount: uint256, 
    bidder: Identity
}
    
Identity: {
    userId: uint256,
    wallet: address
}

Design domain separator
The main purpose is to prevent the signature of one DApp from working in another DApp, which can lead to signature conflicts. In the case of an auction, for example, a bid request in one auction application can be executed successfully in another auction application, which may lead to unnecessary losses.

Specifically, a domain separator is a structure and data such as the following.

{
    name: "Auction dApp", //Dapp name
    version: "2", // Version of the Dapp
    chainId: "1", 
    verifyingContract: "0x1c56346...", //address to verify signature
    salt: "0x43efba6b4..." // random value
}