Sql-server – Always-On Configuration Clarifications

If I install SQL Server FCIs in Production environment(2 node) can i set one secondary to synchronous mode automatic failover and DR(Stand-Alone) server to Async mode?

If you use a SQL Server FCI with Availability Groups, you cannot have automatic failover of the AG but you still get automatic failover of the FCI. The FCI will be one instance and the DR secondary will be another (as FCI are logically a single instance).

Total 3 SQL Servers (Primary Sync,Secondary Sync and Secondary Async(Stand-Alone)) is it possible ?

This is possible, but you're going to use the FCI from your first question then there will only ever be 2 instances, so you'd have Primary Sync and secondary async.

If SQL Server Cluster(2 Instances) is configured in windows 2 node cluster,is synchronous mode possible ?

I'm not sure what you mean by SQL Server cluster and windows cluster. If you are talking FCIs, you wouldn't be able to AG between the FCIs because they'd share the same set of nodes.

Should all the SQL Servers should be stand-alone to configure Always-ON synchronous mode and automatic failover?

They don't have to be. It really depends on what you're trying to solve for. Remember that each secondary will have a copy of the database and will need to have the log blocks be transported to it. This may or may not be doable with the infrastructure available.

Two SQL Servers in Production site,can i set secondary as Synchronous mode with automatic failover ?

Assuming neither are in a SQL Server FCI, yes and you can do it on the fly (though it may take time to get in sync).

Where do you see an explicit recommendation of 8 files? This is certainly not universal. The guidance is 1 file per core, up to 8 cores. If you have more than 8 cores, start with 8, and only add more (in groups of 4) if you actually observe the type of allocation contention that can be relieved by additional files (see this post for a way to determine this). If you're not seeing any of this contention, there's nothing more to do.

Be sure all files are equally sized, with identical autogrowth settings (specified in MB, NOT %), and that you have TFs 1117 and 1118 enabled (though those are no longer necessary starting with SQL Server 2016). This post may also be useful, as well as the links it points to.

Do not make your file sizes small to start out with; this is a common tactic that almost never works out well. Just pre-allocate all of the space you can afford to give them. Forcing them to grow (and then shrink on every restart or failover) just adds unnecessary pressure on your workload, and doesn't accomplish anything (what are you going to do with temporarily free space?). If tempdb is going to fill the drive(s), it doesn't really matter if the files started out small or not; it's still a problem when you get there.